Systems and methods for transforming instructions for metadata processing

ABSTRACT

According to at least one aspect, a hardware system include a host processor, a policy engine, and an interlock is provided. These components can interoperate to enforce security policies. The host processor can execute an instruction and provide instruction information to the policy engine and the result of the executed instruction to the interlock. The policy engine can determine whether the executed instruction is allowable according to one or more security policies using the instruction information. The interlock can buffer the result of the executed instruction until an indication is received from the policy engine that the instruction was allowable. The interlock can then release the result of the executed instruction. The policy engine can be configured to transform instructions received from the host processor or add inserted instructions to the policy evaluation pipeline to increase the flexibility of the policy engine and enable enforcement of the security policies.

RELATED APPLICATIONS

This application claims the benefit under 35 U.S.C. § 119(e) of U.S.Provisional Patent Application Ser. No. 62/635,319, filed on Feb. 26,2018, titled “SYSTEMS AND METHODS FOR TRANSFORMING INSTRUCTIONS FORMETADATA PROCESSING,” bearing Attorney Docket No. D0821.70001US01, U.S.Provisional Patent Application Ser. No. 62/625,746, filed on Feb. 2,2018, titled “SYSTEMS AND METHODS FOR TRANSLATING BETWEEN INSTRUCTIONSET ARCHITECTURES,” bearing Attorney Docket No. D0821.70001US00, andU.S. Provisional Patent Application Ser. No. 62/625,802, filed on Feb.2, 2018, titled “SYSTEMS AND METHODS FOR SECURING INTERRUPT SERVICEROUTINE ENTRY,” bearing Attorney Docket No. D0821.70004US00.

This application is being filed on the same day as:

-   -   International Patent application Ser. No. ______, titled        “SYSTEMS AND METHODS FOR SECURE INITIALIZATION,” bearing        Attorney Docket No. D0821.70000WO00, claiming the benefit under        35 U.S.C. § 119(e) of U.S. Provisional Patent Application Ser.        No. 62/625,822, filed on Feb. 2, 2018, titled “SYSTEMS AND        METHODS FOR SECURE INITIALIZATION,” bearing Attorney Docket No.        D0821.70000US00, and U.S. Provisional Patent Application Ser.        No. 62/635,289, filed on Feb. 26, 2018, titled “SYSTEMS AND        METHODS FOR SECURE INITIALIZATION,” bearing Attorney Docket No.        D0821.70000US01; and    -   International Patent application Ser. No. ______, titled        “SYSTEMS AND METHODS FOR POST CACHE INTERLOCKING,” bearing        Attorney Docket No. D0821.70003WO00, claiming the benefit under        35 U.S.C. § 119(e) of U.S. Provisional Patent Application Ser.        No. 62/625,770, titled “SYSTEMS AND METHODS FOR POST CACHE        INTERLOCKING,” filed on Feb. 2, 2018, bearing Attorney Docket        No. D0821.70003US00, and Provisional Patent Application Ser. No.        62/635,475, titled “SYSTEMS AND METHODS FOR POST CACHE        INTERLOCKING,” filed on Feb. 26, 2018, bearing Attorney Docket        No. D0821.70003US01.

Each of the above-referenced application is hereby incorporated byreference in its entirety.

BACKGROUND

Computer security has become an increasingly urgent concern at alllevels of society, from individuals to businesses to governmentinstitutions. For example, in 2015, security researchers identified azero-day vulnerability that would have allowed an attacker to hack intoa Jeep Cherokee's on-board computer system via the Internet and takecontrol of the vehicle's dashboard functions, steering, brakes, andtransmission. In 2017, the WannaCry ransomware attack was estimated tohave affected more than 200,000 computers worldwide, causing at leasthundreds of millions of dollars in economic losses. Notably, the attackcrippled operations at several National Health Service hospitals in theUK. In the same year, a data breach at Equifax, a US consumer creditreporting agency, exposed person data such as full names, socialsecurity numbers, birth dates, addresses, driver's license numbers,credit card numbers, etc. That attack is reported to have affected over140 million consumers.

Security professionals are constantly playing catch-up with attackers.As soon as a vulnerability is reported, security professionals race topatch the vulnerability. Individuals and organizations that fail topatch vulnerabilities in a timely manner (e.g., due to poor governanceand/or lack of resources) become easy targets for attackers.

Some security software monitors activities on a computer and/or within anetwork, and looks for patterns that may be indicative of an attack.Such an approach does not prevent malicious code from being executed inthe first place. Often, the damage has been done by the time anysuspicious pattern emerges.

SUMMARY

According to at least one aspect, a method is provided. The methodcomprises the acts of: receiving first instruction informationassociated with a first instruction; accessing a first data structureassociated with the first instruction; determining, based at least inpart on the first data structure, whether to perform first processing orsecond processing; in response to determining that the first processingis to be performed, performing the first processing, comprising:identifying first metadata from the first data structure associated withthe first instruction; and outputting the first instruction informationalong with the first metadata; in response to determining that thesecond processing is to be performed, performing the second processing,comprising: identifying location information from the first datastructure associated with the first instruction; using the locationinformation to access at least one second data structure; identifying,from the at least one second data structure, second instructioninformation associated with at least one second instruction andcorresponding second metadata; and outputting the second instructioninformation along with the corresponding second metadata.

In some embodiments, the at least one second instruction comprises aplurality of second instructions; and the second metadata comprises aplurality of pieces of second metadata corresponding, respectively tothe plurality of second instructions.

In some embodiments, the act of receiving the first instructioninformation comprises: receiving the first instruction information froma hardware translator programmed to translate instruction information inan input instruction set architecture (ISA) to instruction informationin an output ISA; and the first instruction information is in the outputISA.

In some embodiments, the method further comprises acts of: receivingthird instruction information from a host processor, the thirdinstruction information being in the input ISA; and translating, by thehardware translator, the third instruction information into the firstinstruction information, which is in the output ISA.

In some embodiments, the act of receiving the first instructioninformation comprises retrieving the first instruction information froma memory location, and the method further comprises acts of:translating, by a software translator, third instruction information inan input instruction set architecture (ISA) into the first instructioninformation, wherein the first instruction information is in an outputISA; and storing, by the software translator, the first instructioninformation at the memory location.

In some embodiments, the act of accessing a first data structurecomprises: accessing the first data structure from an entry in a tag maptable, the entry being associated with the first instruction.

In some embodiments, the act of accessing a first data structurecomprises: accessing a pointer from an entry in a tag map table, theentry being associated with the first instruction; and using the pointerto access the first data structure from a metadata memory.

In some embodiments, the method further comprises an act of: identifyinga flag from the first data structure associated with the firstinstruction.

In some embodiments, determining whether to perform first processing orsecond processing based at least in part on the first data structurecomprises: determining whether to perform first processing or secondprocessing based at least in part on the flag.

In some embodiments, the first instruction is a first branch instructionin an instruction path comprising the first branch instruction thatstarts the instruction path, a second branch instruction that ends theinstruction path, and at least one intermediate instruction between thefirst branch instruction and the second branch instruction.

In some embodiments, the at least one second instruction performs a sameset operations as the instruction path.

In some embodiments, the method further comprises acts of: identifying aset of one or more operations that are performed by the instruction paththat comprises a smaller number of operations than instructions in theinstruction path; and generating the second instruction informationassociated with the at least one second instruction based on the set ofone or more operations.

According to at least one aspect, a method is provided. The methodcomprises receiving first instruction information associated with afirst instruction in a first instruction set architecture (ISA);obtaining second instruction information associated with at least onesecond instruction that corresponds to the first instruction and is in asecond ISA that is different from the first ISA, wherein the act ofobtaining the second instruction information is performed using a set ofrelationships between a first plurality of instructions in the first ISAincluding the first instruction and a second plurality of instructionsin the second ISA including the at least one second instruction, whereinthe set of relationships comprises a relationship between a singleinstruction in the first plurality of instructions that maps to a set oftwo or more instructions in the second plurality of instructions;identifying metadata associated with the at least one secondinstruction; determining whether the first instruction violates at leastone rule using the metadata associated with the at least one secondinstruction; and responsive to the first instruction violating the atleast one rule, outputting an indication that the first instructionviolates the at least one rule.

According to at least one aspect, a method is provided. The methodcomprises receiving, using tag processing hardware, instructioninformation associated with an instruction that is a first instructionafter a context change; associating, using the tag processing hardware,metadata with the received instruction information, wherein the metadatacomprises an indication that the received instruction information isassociated with the first instruction after the context change;triggering, using the tag processing hardware, a policy processor toread the metadata associated with the received instruction information;and modifying, at least in part using the policy processor, at leastsome metadata associated with a first storage location and at least somemetadata associated with a second, different storage location responsiveto reading the metadata associated with the received instruction.

In some embodiments, receiving the instruction information comprises:receiving instruction information associated with an instruction that isa first instruction in an interrupt service routine (ISR).

In some embodiments, the first storage location is a storage location ofan interrupt programmable counter value when the host processor is notexecuting the ISR and wherein the second storage location is a storagelocation of the interrupt programmable counter value when the hostprocessor is executing the ISR.

According to at least one aspect, a policy engine is provided. Thepolicy engine can include at least one of tag processing hardware or apolicy processor. The at least one of tag processing hardware or apolicy processor can be configured to perform a set of operations. Theoperations can include receiving first instruction informationassociated with at least one first instruction executed by a hostprocessor. The operations can include transforming the first instructioninformation into second instruction information associated with at leastone second instruction. The operations can include determining the atleast one first instruction is allowable according to a policy usingsecond metadata corresponding to the at least one second instruction.The operations can further include providing, to an interlock, anindication to provide a queued result of executing the at least onefirst instruction.

According to at least one aspect, another system is provided. Thissystem can include a policy engine. The policy engine can be configuredto perform a set of operations. The operations can include receivingfirst instruction information associated with at least one firstinstruction executed by a host processor. The operations can furtherinclude, in response to receiving the first instruction information,obtaining second instruction information associated with at least onesecond instruction and second metadata associated with the secondinstruction. The operations can also include generating update metadatausing at least one of the second instruction information and secondmetadata. The operations can further include updating at least one of atag map table, tag register file, or metadata memory using the generatedupdate metadata. The operations can also include determining at leastone instruction previously executed by a host processor is allowableaccording to at least one policy, the determination based on the updatedat least one of the tag map table, tag register file, or metadatamemory. The operations can additionally include providing, to aninterlock in response to the determination, an indication to release aqueued result of executing the at least one first instruction.

According to at least one aspect, a further system is provided. Thissystem can include a policy engine. The policy engine can be configuredto perform a set of operations. The operations can include receivinginstruction information associated with a first instruction in a hostInstruction Set Architecture (ISA) executed by a host processor. Theoperations can also include generating a translation of the instructioninformation, the translation not in the host ISA. The operations canadditionally include obtaining metadata using the translation of theinstruction information. The operations can also include determining theat least one first instruction is allowable according to a policy usingthe metadata. The operations can further include providing, to aninterlock, an indication to release a queued result of executing the atleast one first instruction.

According to at least one aspect, a further system is provided. Thissystem can include a policy engine. The policy engine can be configuredto perform a set of operations. The operations can include receivinginstruction information associated with a first instruction in a hostInstruction Set Architecture (ISA) used by a host processor. Theoperations can further include generating a translation of theinstruction information, the translation not in the host ISA. Theoperations can also include obtaining metadata using an address of thefirst instruction; and determining, using the metadata, whether the atleast one first instruction is allowable according to a policy.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 shows an illustrative hardware system 100 for enforcing policies,in accordance with some embodiments.

FIG. 2 shows an illustrative software system 200 for enforcing policies,in accordance with some embodiments.

FIG. 3 shows an illustrative implementation of the tagging processinghardware 140 of FIG. 1 for associating metadata with instructioninformation, in accordance with some embodiments.

FIG. 4 shows an illustrative policy enforcement process performed by thepolicy engine using transformed instructions.

FIG. 5 shows an illustrative policy enforcement process by the policyengine using added instructions.

FIG. 6 shows an illustrative hardware system 600 for enforcing policiesusing a policy engine, in accordance with some embodiments.

FIG. 7 shows, schematically, an illustrative computer 700 on which anyaspect of the present disclosure may be implemented.

DETAILED DESCRIPTION

Many vulnerabilities exploited by attackers trace back to a computerarchitectural design where data and executable instructions areintermingled in a same memory. This intermingling allows an attacker toinject malicious code into a remote computer by disguising the maliciouscode as data. For instance, a program may allocate a buffer in acomputer's memory to store data received via a network. If the programreceives more data than the buffer can hold, but does not check the sizeof the received data prior to writing the data into the buffer, part ofthe received data would be written beyond the buffer's boundary, intoadjacent memory. An attacker may exploit this behavior to injectmalicious code into the adjacent memory. If the adjacent memory isallocated for executable code, the malicious code may eventually beexecuted by the computer.

Techniques have been proposed to make computer hardware more securityaware. For instance, memory locations may be associated with metadatafor use in enforcing security policies, and instructions may be checkedfor compliance with the security policies. For example, given aninstruction to be executed, metadata associated with the instructionand/or metadata associated with one or more operands of the instructionmay be checked to determine if the instruction should be allowed.Additionally, or alternatively, appropriate metadata may be associatedwith an output of the instruction.

FIG. 1 shows an illustrative hardware system 100 for enforcing policies,in accordance with some embodiments. In this example, the system 100includes a host processor 110, which may have any suitable instructionset architecture (ISA) such as a reduced instruction set computing(RISC) architecture or a complex instruction set computing (CISC)architecture. The host processor 110 may perform memory accesses via awrite interlock 112. The write interlock 112 may be connected to asystem bus 115 configured to transfer data between various componentssuch as the write interlock 112, an application memory 120, a metadatamemory 125, a read-only memory (ROM) 130, one or more peripherals 135,etc.

In some embodiments, data that is manipulated (e.g., modified, consumed,and/or produced) by the host processor 110 may be stored in theapplication memory 120. Such data is referred to herein as “applicationdata,” as distinguished from metadata used for enforcing policies. Thelatter may be stored in the metadata memory 125. It should beappreciated that application data may include data manipulated by anoperating system (OS), instructions of the OS, data manipulated by oneor more user applications, and/or instructions of the one or more userapplications.

In some embodiments, the application memory 120 and the metadata memory125 may be physically separate, and the host processor 110 may have noaccess to the metadata memory 125. In this manner, even if an attackersucceeds in injecting malicious code into the application memory 120 andcausing the host processor 110 to execute the malicious code, themetadata memory 125 may not be affected. However, it should beappreciated that aspects of the present disclosure are not limited tostoring application data and metadata on physically separate memories.Additionally, or alternatively, metadata may be stored in a same memoryas application data, and a memory management component may be used thatimplements an appropriate protection scheme to prevent instructionsexecuting on the host processor 110 from modifying the metadata.Additionally, or alternatively, metadata may be intermingled withapplication data in a same memory, and one or more policies may be usedto protect the metadata.

In some embodiments, tag processing hardware 140 may be provided toensure that instructions being executed by the host processor 110 complywith one or more policies. The tag processing hardware 140 may includeany suitable circuit component or combination of circuit components. Forinstance, the tag processing hardware 140 may include a tag map table142 that maps addresses in the application memory 120 to addresses inthe metadata memory 125. For example, the tag map table 142 may mapaddress X in the application memory 120 to address Y in the metadatamemory 125. Such an address Y is referred to herein as a “metadata tag”or simply a “tag.” A value stored at the address Y is also referred toherein as a “metadata tag” or simply a “tag.”

In some embodiments, a value stored at the address Y may in turn be anaddress Z. Such indirection may be repeated any suitable number oftimes, and may eventually lead to a data structure in the metadatamemory 125 for storing metadata. Such metadata, as well as anyintermediate address (e.g., the address Z), are also referred to hereinas “metadata tags” or simply “tags.”

It should be appreciated that aspects of the present disclosure are notlimited to a tag map table that stores addresses in a metadata memory.In some embodiments, a tag map table entry itself may store metadata, sothat the tag processing hardware 140 may be able to access the metadatawithout performing a memory operation. In some embodiments, a tag maptable entry may store a selected bit pattern, where a first portion ofthe bit pattern may encode metadata, and a second portion of the bitpattern may encode an address in a metadata memory where furthermetadata may be stored. This may provide a desired balance between speedand expressivity. For instance, the tag processing hardware 140 may beable to check certain policies quickly, using only the metadata storedin the tag map table entry itself. For other policies with more complexrules, the tag processing hardware 140 may access the further metadatastored in the metadata memory 125.

Referring again to FIG. 1, by mapping application memory addresses tometadata memory addresses, the tag map table 142 may create anassociation between application data and metadata that describes theapplication data. In one example, metadata stored at the metadata memoryaddress Y and thus associated with application data stored at theapplication memory address X may indicate that the application data maybe readable, writable, and/or executable. In another example, metadatastored at the metadata memory address Y and thus associated withapplication data stored at the application memory address X may indicatea type of the application data (e.g., integer, pointer, 16-bit word,32-bit word, etc.). Depending on a policy to be enforced, any suitablemetadata relevant for the policy may be associated with a piece ofapplication data.

In some embodiments, a metadata memory address Z may be stored at themetadata memory address Y. Metadata to be associated with theapplication data stored at the application memory address X may bestored at the metadata memory address Z, instead of (or in addition to)the metadata memory address Y. For instance, a binary representation ofa metadata symbol “RED” may be stored at the metadata memory address Z.By storing the metadata memory address Z in the metadata memory addressY, the application data stored at the application memory address X maybe tagged “RED.”

In this manner, the binary representation of the metadata symbol “RED”may be stored only once in the metadata memory 120. For instance, ifapplication data stored at another application memory address X′ is alsoto be tagged “RED,” the tag map table 142 may map the application memoryaddress X′ to a metadata memory address Y′ where the metadata memoryaddress Z is also stored.

Moreover, in this manner, tag update may be simplified. For instance, ifthe application data stored at the application memory address X is to betagged “BLUE” at a subsequent time, a metadata memory address Z′ may bewritten at the metadata memory address Y, to replace the metadata memoryaddress Z, and a binary representation of the metadata symbol “BLUE” maybe stored at the metadata memory address Z′.

Thus, the inventors have recognized and appreciated that a chain ofmetadata memory addresses of any suitable length N may be used fortagging, including N=0 (e.g., where a binary representation of ametadata symbol is stored at the metadata memory address Y itself).

The association between application data and metadata (also referred toherein as “tagging”) may be done at any suitable level of granularity,and/or variable granularity. For instance, tagging may be done on aword-by-word basis. Additionally, or alternatively, a region in memorymay be mapped to a single tag, so that all words in that region areassociated with the same metadata. This may advantageously reduce a sizeof the tag map table 142 and/or the metadata memory 125. For example, asingle tag may be maintained for an entire address range, as opposed tomaintaining multiple tags corresponding, respectively, to differentaddresses in the address range.

In some embodiments, the tag processing hardware 140 may be configuredto apply one or more security rules to metadata associated with aninstruction and/or metadata associated with one or more operands of theinstruction to determine if the instruction should be allowed. Forinstance, the host processor 110 may fetch and execute an instruction,and may queue a result of executing the instruction into the writeinterlock 112. Before the result is written back into the applicationmemory 120, the host processor 110 may send, to the tag processinghardware 140, an instruction type (e.g., opcode), an address where theinstruction is stored, one or more memory addresses referenced by theinstruction, and/or one or more register identifiers. Such a registeridentifier may identify a register used by the host processor 110 inexecuting the instruction, such as a register for storing an operand ora result of the instruction.

In some embodiments, destructive read instructions may be queued inaddition to, or instead of, write instructions. For instance, subsequentinstructions attempting to access a target address of a destructive readinstruction may be queued in a memory region that is not cached. If andwhen it is determined that the destructive read instruction should beallowed, the queued instructions may be loaded for execution.

In some embodiments, a destructive read instruction may be allowed toproceed, and data read from a target address may be captured in abuffer. If and when it is determined that the destructed readinstruction should be allowed, the data captured in the buffer may bediscarded. If and when it is determined that the destructive readinstruction should not be allowed, the data captured in the buffer maybe restored to the target address. Additionally, or alternatively, asubsequent read may be serviced by the buffered data.

It should be appreciated that aspects of the present disclosure are notlimited to performing metadata processing on instructions that have beenexecuted by a host processor, such as instructions that have beenretired by the host processor's execution pipeline. In some embodiments,metadata processing may be performed on instructions before, during,and/or after the host processor's execution pipeline.

In some embodiments, given an address received from the host processor110 (e.g., an address where an instruction is stored, or an addressreferenced by an instruction), the tag processing hardware 140 may usethe tag map table 142 to identify a corresponding tag. Additionally, oralternatively, for a register identifier received from the hostprocessor 110, the tag processing hardware 140 may access a tag from atag register file 146 within the tag processing hardware 140.

In some embodiments, if an application memory address does not have acorresponding tag in the tag map table 142, the tag processing hardware140 may send a query to a policy processor 150. The query may includethe application memory address in question, and the policy processor 150may return a tag for that application memory address. Additionally, oralternatively, the policy processor 150 may create a new tag map entryfor an address range including the application memory address. In thismanner, the appropriate tag may be made available, for future reference,in the tag map table 142 in association with the application memoryaddress in question.

In some embodiments, the tag processing hardware 140 may send a query tothe policy processor 150 to check if an instruction executed by the hostprocessor 110 should be allowed. The query may include one or moreinputs, such as an instruction type (e.g., opcode) of the instruction, atag for a program counter, a tag for an application memory address fromwhich the instruction is fetched (e.g., a word in memory to which theprogram counter points), a tag for a register in which an operand of theinstruction is stored, and/or a tag for an application memory addressreferenced by the instruction. In one example, the instruction may be aload instruction, and an operand of the instruction may be anapplication memory address from which application data is to be loaded.The query may include, among other things, a tag for a register in whichthe application memory address is stored, as well as a tag for theapplication memory address itself. In another example, the instructionmay be an arithmetic instruction, and there may be two operands. Thequery may include, among other things, a first tag for a first registerin which a first operand is stored, and a second tag for a secondregister in which a second operand is stored.

It should also be appreciated that aspects of the present disclosure arenot limited to performing metadata processing on a single instruction ata time. In some embodiments, multiple instructions in a host processor'sISA may be checked together as a bundle, for example, via a single queryto the policy processor 150. Such a query may include more inputs toallow the policy processor 150 to check all of the instructions in thebundle. Similarly, a CISC instruction, which may correspond semanticallyto multiple operations, may be checked via a single query to the policyprocessor 150, where the query may include sufficient inputs to allowthe policy processor 150 to check all of the constituent operationswithin the CISC instruction.

In some embodiments, the policy processor 150 may include a configurableprocessing unit, such as a microprocessor, a field-programmable gatearray (FPGA), and/or any other suitable circuitry. The policy processor150 may have loaded therein one or more policies that describe allowedoperations of the host processor 110. In response to a query from thetag processing hardware 140, the policy processor 150 may evaluate oneor more of the policies to determine if an instruction in questionshould be allowed. For instance, the tag processing hardware 140 maysend an interrupt signal to the policy processor 150, along with one ormore inputs relating to the instruction in question (e.g., as describedabove). The policy processor 150 may store the inputs of the query in aworking memory (e.g., in one or more queues) for immediate or deferredprocessing. For example, the policy processor 150 may prioritizeprocessing of queries in some suitable manner (e.g., based on a priorityflag associated with each query).

In some embodiments, the policy processor 150 may evaluate one or morepolicies on one or more inputs (e.g., one or more input tags) todetermine if an instruction in question should be allowed. If theinstruction is not to be allowed, the policy processor 150 may so notifythe tag processing hardware 140. If the instruction is to be allowed,the policy processor 150 may compute one or more outputs (e.g., one ormore output tags) to be returned to the tag processing hardware 140. Asone example, the instruction may be a store instruction, and the policyprocessor 150 may compute an output tag for an application memoryaddress to which application data is to be stored. As another example,the instruction may be an arithmetic instruction, and the policyprocessor 150 may compute an output tag for a register for storing aresult of executing the arithmetic instruction.

In some embodiments, the policy processor 150 may be programmed toperform one or more tasks in addition to, or instead of, those relatingto evaluation of policies. For instance, the policy processor 150 mayperform tasks relating to tag initialization, boot loading, applicationloading, memory management (e.g., garbage collection) for the metadatamemory 125, logging, debugging support, and/or interrupt processing. Oneor more of these tasks may be performed in the background (e.g., betweenservicing queries from the tag processing hardware 140).

In some embodiments, the tag processing hardware 140 may include a rulecache 144 for mapping one or more input tags to a decision and/or one ormore output tags. For instance, a query into the rule cache 144 may besimilarly constructed as a query to the policy processor 150 to check ifan instruction executed by the host processor 110 should be allowed. Ifthere is a cache hit, the rule cache 144 may output a decision as towhether to the instruction should be allowed, and/or one or more outputtags (e.g., as described above in connection with the policy processor150). Such a mapping in the rule cache 144 may be created using a queryresponse from the policy processor 150. However, that is not required,as in some embodiments, one or more mappings may be installed into therule cache 144 ahead of time.

In some embodiments, the rule cache 144 may be used to provide aperformance enhancement. For instance, before querying the policyprocessor 150 with one or more input tags, the tag processing hardware140 may first query the rule cache 144 with the one or more input tags.In case of a cache hit, the tag processing hardware 140 may proceed witha decision and/or one or more output tags from the rule cache 144,without querying the policy processor 150. This may provide asignificant speedup. In case of a cache miss, the tag processinghardware 140 may query the policy processor 150 and install a responsefrom the policy processor 150 into the rule cache 144 for potentialfuture use.

In some embodiments, if the tag processing hardware 140 determines thatan instruction in question should be allowed (e.g., based on a hit inthe rule cache 144, or a miss in the rule cache 144, followed by aresponse from the policy processor 150 indicating no policy violationhas been found), the tag processing hardware 140 may indicate to thewrite interlock 112 that a result of executing the instruction may bewritten back to memory. Additionally, or alternatively, the tagprocessing hardware 140 may update the metadata memory 125, the tag maptable 142, and/or the tag register file 146 with one or more output tags(e.g., as received from the rule cache 144 or the policy processor 150).As one example, for a store instruction, the metadata memory 125 may beupdated via an address translation by the tag map table 142. Forinstance, an application memory address referenced by the storeinstruction may be used to look up a metadata memory address from thetag map table 142, and metadata received from the rule cache 144 or thepolicy processor 150 may be stored to the metadata memory 125 at themetadata memory address. As another example, where metadata to beupdated is stored in an entry in the tag map table 142 (as opposed tobeing stored in the metadata memory 125), that entry in the tag maptable 142 may be updated. As another example, for an arithmeticinstruction, an entry in the tag register file 146 corresponding to aregister used by the host processor 110 for storing a result ofexecuting the arithmetic instruction may be updated with an appropriatetag.

In some embodiments, if the tag processing hardware 140 determines thatthe instruction in question represents a policy violation (e.g., basedon a miss in the rule cache 144, followed by a response from the policyprocessor 150 indicating a policy violation has been found), the tagprocessing hardware 140 may indicate to the write interlock 112 that aresult of executing the instruction should be discarded, instead ofbeing written back to memory. Additionally, or alternatively, the tagprocessing hardware 140 may send an interrupt to the host processor 110.In response to receiving the interrupt, the host processor 110 mayswitch to any suitable violation processing code. For example, the hostprocessor 100 may halt, reset, log the violation and continue, performan integrity check on application code and/or application data, notifyan operator, etc.

In some embodiments, the tag processing hardware 140 may include one ormore configuration registers. Such a register may be accessible (e.g.,by the policy processor 150) via a configuration interface of the tagprocessing hardware 140. In some embodiments, the tag register file 146may be implemented as configuration registers. Additionally, oralternatively, there may be one or more application configurationregisters and/or one or more metadata configuration registers.

Although details of implementation are shown in FIG. 1 and discussedabove, it should be appreciated that aspects of the present disclosureare not limited to the use of any particular component, or combinationof components, or to any particular arrangement of components. Forinstance, in some embodiments, one or more functionalities of the policyprocessor 150 may be performed by the host processor 110. As an example,the host processor 110 may have different operating modes, such as auser mode for user applications and a privileged mode for an operatingsystem. Policy-related code (e.g., tagging, evaluating policies, etc.)may run in the same privileged mode as the operating system, or adifferent privileged mode (e.g., with even more protection againstprivilege escalation).

FIG. 2 shows an illustrative software system 200 for enforcing policies,in accordance with some embodiments. For instance, the software system200 may be programmed to generate executable code and/or load theexecutable code into the illustrative hardware system 100 shown in FIG.1.

In the example shown in FIG. 2, the software system 200 includes asoftware toolchain having a compiler 205, a linker 210, and a loader215. The compiler 205 may be programmed to process source code intoexecutable code, where the source code may be in a higher-level languageand the executable code may be in a lower level language. The linker 210may be programmed to combine multiple object files generated by thecompiler 205 into a single object file to be loaded by the loader 215into memory (e.g., the illustrative application memory 120 in theexample of FIG. 1). Although not shown, the object file output by thelinker 210 may be converted into a suitable format and stored inpersistent storage, such as flash memory, hard disk, read-only memory(ROM), etc. The loader 215 may retrieve the object file from thepersistent storage, and load the object file into random-access memory(RAM).

In some embodiments, the compiler 205 may be programmed to generateinformation for use in enforcing policies. For instance, as the compiler205 translates source code into executable code, the compiler 205 maygenerate information regarding data types, program semantics and/ormemory layout. As one example, the compiler 205 may be programmed tomark a boundary between one or more instructions of a function and oneor more instructions that implement calling convention operations (e.g.,passing one or more parameters from a caller function to a calleefunction, returning one or more values from the callee function to thecaller function, storing a return address to indicate where execution isto resume in the caller function's code when the callee function returnscontrol back to the caller function, etc.). Such boundaries may be used,for instance, during initialization to tag certain instructions asfunction prologue or function epilogue. At run time, a stack policy maybe enforced so that, as function prologue instructions execute, certainlocations in a call stack (e.g., where a return address is stored) maybe tagged as “frame” locations, and as function epilogue instructionsexecute, the “frame” tags may be removed. The stack policy may indicatethat instructions implementing a body of the function (as opposed tofunction prologue and function epilogue) only have read access to“frame” locations. This may prevent an attacker from overwriting areturn address and thereby gaining control.

As another example, the compiler 205 may be programmed to performcontrol flow analysis, for instance, to identify one or more controltransfer points and respective destinations. Such information may beused in enforcing a control flow policy. As yet another example, thecompiler 205 may be programmed to perform type analysis, for example, byapplying type labels such as Pointer, Integer, Floating-Point Number,etc. Such information may be used to enforce a policy that preventsmisuse (e.g., using a floating-point number as a pointer).

Although not shown in FIG. 2, the software system 200 may, in someembodiments, include a binary analysis component programmed to take, asinput, object code produced by the linker 210 (as opposed to sourcecode), and perform one or more analyses similar to those performed bythe compiler 205 (e.g., control flow analysis, type analysis, etc.).

In the example of FIG. 2, the software system 200 further includes apolicy compiler 220 and a policy linker 225. The policy compiler 220 maybe programmed to translate a policy written in a policy language intopolicy code. For instance, the policy compiler 220 may output policycode in C or some other suitable programming language. Additionally, oralternatively, the policy compiler 220 may output one or more metadatasymbols referenced by the policy. At initialization, such a metadatasymbol may be associated with one or more memory locations, registers,and/or other machine state of a target system, and may be resolved intoa binary representation of metadata to be loaded into a metadata memoryor some other hardware storage (e.g., registers) of the target system.As discussed above, such a binary representation of metadata, or apointer to a location at which the binary representation is stored, issometimes referred to herein as a “tag.”

It should be appreciated that aspects of the present disclosure are notlimited to resolving metadata symbols at load time. In some embodiments,one or more metadata symbols may be resolved statically (e.g., atcompile time or link time). For example, the policy compiler 220 mayprocess one or more applicable policies, and resolve one or moremetadata symbols defined by the one or more policies into astatically-defined binary representation. Additionally, oralternatively, the policy linker 225 may resolve one or more metadatasymbols into a statically-defined binary representation, or a pointer toa data structure storing a statically-defined binary representation. Theinventors have recognized and appreciated that resolving metadatasymbols statically may advantageously reduce load time processing.However, aspects of the present disclosure are not limited to resolvingmetadata symbols in any particular manner.

In some embodiments, the policy linker 225 may be programmed to processobject code (e.g., as output by the linker 210), policy code (e.g., asoutput by the policy compiler 220), and/or a target description, tooutput an initialization specification. The initialization specificationmay be used by the loader 215 to securely initialize a target systemhaving one or more hardware components (e.g., the illustrative hardwaresystem 100 shown in FIG. 1) and/or one or more software components(e.g., an operating system, one or more user applications, etc.).

In some embodiments, the target description may include descriptions ofa plurality of named entities. A named entity may represent a componentof a target system. As one example, a named entity may represent ahardware component, such as a configuration register, a program counter,a register file, a timer, a status flag, a memory transfer unit, aninput/output device, etc. As another example, a named entity mayrepresent a software component, such as a function, a module, a driver,a service routine, etc.

In some embodiments, the policy linker 225 may be programmed to searchthe target description to identify one or more entities to which apolicy pertains. For instance, the policy may map certain entity namesto corresponding metadata symbols, and the policy linker 225 may searchthe target description to identify entities having those entity names.The policy linker 225 may identify descriptions of those entities fromthe target description, and use the descriptions to annotate, withappropriate metadata symbols, the object code output by the linker 210.For instance, the policy linker 225 may apply a Read label to a .rodatasection of an Executable and Linkable Format (ELF) file, a Read labeland a Write label to a .data section of the ELF file, and an Executelabel to a .text section of the ELF file. Such information may be usedto enforce a policy for memory access control and/or executable codeprotection (e.g., by checking read, write, and/or execute privileges).

It should be appreciated that aspects of the present disclosure are notlimited to providing a target description to the policy linker 225. Insome embodiments, a target description may be provided to the policycompiler 220, in addition to, or instead of, the policy linker 225. Thepolicy compiler 220 may check the target description for errors. Forinstance, if an entity referenced in a policy does not exist in thetarget description, an error may be flagged by the policy compiler 220.Additionally, or alternatively, the policy compiler 220 may search thetarget description for entities that are relevant for one or morepolicies to be enforced, and may produce a filtered target descriptionthat includes entities descriptions for the relevant entities only. Forinstance, the policy compiler 220 may match an entity name in an “init”statement of a policy to be enforced to an entity description in thetarget description, and may remove from the target description entitydescriptions with no corresponding “init” statement.

In some embodiments, the loader 215 may initialize a target system basedon an initialization specification produced by the policy linker 225.For instance, with reference to the example of FIG. 1, the loader 215may load data and/or instructions into the application memory 120, andmay use the initialization specification to identify metadata labelsassociated with the data and/or instructions being loaded into theapplication memory 120. The loader 215 may resolve the metadata labelsin the initialization specification into respective binaryrepresentations. However, it should be appreciated that aspects of thepresent disclosure are not limited to resolving metadata labels at loadtime. In some embodiments, a universe of metadata labels may be knownduring policy linking, and therefore metadata labels may be resolved atthat time, for example, by the policy linker 225. This mayadvantageously reduce load time processing of the initializationspecification.

In some embodiments, the policy linker 225 and/or the loader 215 maymaintain a mapping of binary representations of metadata back tometadata labels. Such a mapping may be used, for example, by a debugger230. For instance, in some embodiments, the debugger 230 may be providedto display a human readable version of an initialization specification,which may list one or more entities and, for each entity, a set of oneor more metadata labels associated with the entity. Additionally, oralternatively, the debugger 230 may be programmed to display assemblycode annotated with metadata labels, such as assembly code generated bydisassembling object code annotated with metadata labels. An example ofsuch assembly code is shown in FIG. 6 and discussed below. Duringdebugging, the debugger 230 may halt a program during execution, andallow inspection of entities and/or metadata tags associated with theentities, in human readable form. For instance, the debugger 230 mayallow inspection of entities involved in a policy violation and/ormetadata tags that caused the policy violation. The debugger 230 may doso using the mapping of binary representations of metadata back tometadata labels.

In some embodiments, a conventional debugging tool may be extended allowreview of issues related to policy enforcement, for example, asdescribed above. Additionally, or alternatively, a stand-alone policydebugging tool may be provided.

In some embodiments, the loader 215 may load the binary representationsof the metadata labels into the metadata memory 125, and may record themapping between application memory addresses and metadata memoryaddresses in the tag map table 142. For instance, the loader 215 maycreate an entry in the tag map table 142 that maps an application memoryaddress where an instruction is stored in the application memory 120, toa metadata memory address where metadata associated with the instructionis stored in the metadata memory 125. Additionally, or alternatively,the loader 215 may store metadata in the tag map table 142 itself (asopposed to the metadata memory 125), to allow access without performingany memory operation.

In some embodiments, the loader 215 may initialize the tag register file146 in addition to, or instead of, the tag map table 142. For instance,the tag register file 146 may include a plurality of registerscorresponding, respectively, to a plurality of entities. The loader 215may identify, from the initialization specification, metadata associatedwith the entities, and store the metadata in the respective registers inthe tag register file 146.

With reference again to the example of FIG. 1, the loader 215 may, insome embodiments, load policy code (e.g., as output by the policycompiler 220) into the metadata memory 125 for execution by the policyprocessor 150. Additionally, or alternatively, a separate memory (notshown in FIG. 1) may be provided for use by the policy processor 150,and the loader 215 may load policy code and/or associated data into theseparate memory.

In some embodiments, a metadata label may be based on multiple metadatasymbols. For instance, an entity may be subject to multiple policies,and may therefore be associated with different metadata symbolscorresponding, respectively, to the different policies. The inventorshave recognized and appreciated that it may be desirable that a same setof metadata symbols be resolved by the loader 215 to a same binaryrepresentation (which is sometimes referred to herein as a “canonical”representation). For instance, a metadata label {A, B, C} and a metadatalabel {B, A, C} may be resolved by the loader 215 to a same binaryrepresentation. In this manner, metadata labels that are syntacticallydifferent but semantically equivalent may have the same binaryrepresentation.

The inventors have further recognized and appreciated it may bedesirable to ensure that a binary representation of metadata is notduplicated in metadata storage. For instance, as discussed above, theillustrative rule cache 144 in the example of FIG. 1 may map input tagsto output tags, and, in some embodiments, the input tags may be metadatamemory addresses where binary representations of metadata are stored, asopposed to the binary representations themselves. The inventors haverecognized and appreciated that if a same binary representation ofmetadata is stored at two different metadata memory addresses X and Y,the rule cache 144 may not “recognize” the metadata memory address Yeven if the rule cache 144 already stores a mapping for the metadatamemory address X. This may result in a large number of unnecessary rulecache misses, which degrades system performance.

Moreover, the inventors have recognized and appreciated that having aone-to-one correspondence between binary representations of metadata andtheir storage locations may facilitate metadata comparison. Forinstance, equality between two pieces of metadata may be determinedsimply by comparing metadata memory addresses, as opposed to comparingbinary representations of metadata. This may result in significantperformance improvement, especially where the binary representations arelarge (e.g., many metadata symbols packed into a single metadata label).

Accordingly, in some embodiments, the loader 215 may, prior to storing abinary representation of metadata (e.g., into the metadata memory 125),check if the binary representation of metadata has already been stored.If the binary representation of metadata has already been stored,instead of storing it again at a different storage location, the loader215 may refer to the existing storage location. Such a check may be doneat startup and/or when a program is loaded subsequent to startup (withor without dynamic linking).

Additionally, or alternatively, a similar check may be performed when abinary representation of metadata is created as a result of evaluatingone or more policies (e.g., by the illustrative policy processor 150).If the binary representation of metadata has already been stored, areference to the existing storage location may be used (e.g., installedin the illustrative rule cache 144).

In some embodiments, the loader 215 may create a hash table mapping hashvalues to storage locations. Before storing a binary representation ofmetadata, the loader 215 may use a hash function to reduce the binaryrepresentation of metadata into a hash value, and check if the hashtable already contains an entry associated with the hash value. If so,the loader 215 may determine that the binary representation of metadatahas already been stored, and may retrieve, from the entry, informationrelating to the binary representation of metadata (e.g., a pointer tothe binary representation of metadata, or a pointer to that pointer). Ifthe hash table does not already contain an entry associated with thehash value, the loader 215 may store the binary representation ofmetadata (e.g., to a register or a location in a metadata memory),create a new entry in the hash table in association with the hash value,and store appropriate information in the new entry (e.g., a registeridentifier, a pointer to the binary representation of metadata in themetadata memory, a pointer to that pointer, etc.). However, it should beappreciated that aspects of the present disclosure are not limited tothe use of a hash table for keeping track of binary representations ofmetadata that have already been stored. Additionally, or alternatively,other data structures may be used, such as a graph data structure, anordered list, an unordered list, etc. Any suitable data structure orcombination of data structures may be selected based on any suitablecriterion or combination of criteria, such as access time, memory usage,etc.

It should be appreciated that the techniques introduced above anddiscussed in greater detail below may be implemented in any of numerousways, as the techniques are not limited to any particular manner ofimplementation. Examples of details of implementation are providedherein solely for illustrative purposes. Furthermore, the techniquesdisclosed herein may be used individually or in any suitablecombination, as aspects of the present disclosure are not limited to theuse of any particular technique or combination of techniques.

For instance, while examples are discussed herein that include acompiler (e.g., the illustrative compiler 205 and/or the illustrativepolicy compiler 220 in the example of FIG. 2), it should be appreciatedthat aspects of the present disclosure are not so limited. In someembodiments, a software toolchain may be implemented as an interpreter.For example, a lazy initialization scheme may be implemented, where oneor more default symbols (e.g., “UNINITIALIZED”) may be used for taggingat startup, and a policy processor (e.g., the illustrative policyprocessor 150 in the example of FIG. 1) may evaluate one or morepolicies and resolve the one or more default symbols in a just-in-timemanner.

As discussed above, a set of policy rules may be applied to metadataassociated with instructions for a host processor to determine whetherthe instructions should be allowed. Aspects of the present disclosurerelate to techniques to simplify the processing of the metadataassociated with these instructions. In some embodiments, a new techniqueis used to transform the instructions for a host processor to facilitatemetadata processing (e.g., without changing the instruction processed bythe host processor). These techniques may transform instructions in anyof a variety of ways including: breaking down a complex instruction intoa set of two or more simpler instructions (referred to hereinafter as“unrolling”), removing instruction(s) (e.g., removing those instructionsthat are not relevant for metadata processing), adding newinstruction(s) (e.g., adding instructions to capture implicit operationsperformed by the host processor for which there is no explicitinstruction), and/or replacing the instructions altogether (e.g.,swapping one instruction for another, different instruction). Theinventors have recognized and appreciated that these techniques maysimplify a myriad of otherwise complex situations in metadata processingas described in more detail below. Thus, the computation complexity ofcreating a policy and/or determining whether these complex instructionsviolate the policy may be significantly reduced.

These techniques for transforming the instructions for metadataprocessing may be implemented in any of a variety of ways using, forexample, the tag processing hardware 140 in the hardware system 100shown in FIG. 1. In some embodiments, the tag processing hardware 140may receive instruction information associated with an instruction forthe host processor 110 (e.g., an instruction that has been executed bythe host processor 110, an instruction that is currently being executedby the host processor 110, or an instruction that has yet to be executedby the host processor 110). The instruction information associated withthe instruction may include, for example, any information indicative ofthe instruction or any component thereof such as the entire instructionitself, an instruction type (e.g., opcode) of the instruction, anaddress where the instruction is stored, registers where operands arestored, and/or one or more memory addresses referenced by theinstruction. Upon receiving the instruction information, the tagprocessing hardware 140 may determine whether the instruction needs tobe transformed for metadata processing or may be left unchanged. If thetag processing hardware 140 determines that the instruction needs to betransformed, the tag processing hardware 140 may obtain differentinstruction information associated with the transformed instructionsthat may replace the received instruction. Further, the tag processinghardware 140 may obtain the metadata associated with the transformedinstruction. Otherwise, the tag processing hardware 140 may leave thereceived instruction information intact and obtain the metadataassociated with the received instruction information.

The tag processing hardware 140 may make a determination as to whether aparticular instruction needs to be transformed using metadata associatedwith the instruction information, such as a first data structure thatstores information regarding the received instruction information. Thefirst data structure may comprise, for example, either metadata to beprocessed to determine whether the instruction should be allowed or apointer to other data structure(s) (e.g., a second and/or third datastructures) that store instruction information associated withtransformed instruction(s) to be used to override the receivedinstruction information (for metadata processing purposes) and theassociated metadata. The tag map table 142 may directly store the firstdata structure and/or store a pointer to a location of the first datastructure (e.g., a pointer to a location in the metadata memory 125where the first data structure is stored).

The tag processing hardware 140 may determine whether an instructionneeds to be transformed using the first data structure in any of avariety of ways. In some embodiments, the first data structure maycomprise a flag (e.g., a bit) indicative of whether the instructionneeds to be transformed. Thus, the tag processing hardware 140 may readthe flag stored in the first data structure and make the determinationas to whether the instruction needs to be transformed based on the stateof the flag. For example, the tag processing hardware 140 may interpretthe additional information in the first data structure as metadataresponsive to the flag being in the first state and interpret theadditional information in the first data structure as a pointerresponsive to the flag being in the second state. Additionally, oralternatively, the tag processing hardware may be configured tointerpret a certain range of values of the first data structure to beindicative of whether the instruction needs to be transformed. Forexample, the tag processing hardware 140 may interpret the informationin the first data structure as a pointer to a second data structure ifthe value of the first data structure is within a programmed range ofvalues, and interpret the information in the first data structure asmetadata responsive to the value of the first data structure beingoutside the programmed range.

Once the tag processing hardware 140 has determined whether theinstruction needs to be transformed, the tag processing hardware 140 maygenerate the instruction information and associated metadata that may beprovided to the rule cache 144 to determine whether an instruction forthe host processor 110 violates a policy. The particular method employedto generate this information may depend on whether the instructioninformation needs to be transformed. If the tag processing hardware 140determines that the instruction information needs to be transformed, thetag processing hardware 140 may access the other data structuresidentified in the first data structure (e.g., using the pointers in thefirst data structure) to obtain and output the new instructioninformation and the associated metadata. Otherwise, the tag processinghardware 140 may obtain the metadata directly from the first datastructure and output the received instruction information along with theassociated metadata obtained from the first data structure.

The techniques described herein to transform the instructions formetadata processing may advantageously employed to, for example, breakdown complex instructions into multiple smaller instructions (e.g.,unrolling the complex instructions). The inventors have recognized thatcertain instructions in some ISAs may execute several lower-leveloperations. For example, the PUSH instruction in Version 7 of the ARMT32 ISA stores up to 16 values in consecutive memory locations, andincrements a stack pointer register. Thus, a single PUSH instruction maycause state changes in up to 17 different hardware entities (e.g., up to16 memory locations for new values, in addition to the stack pointerregister). Attempting to directly associate metadata with such complexinstructions may become unwieldy, and may increase processing time,memory usage, and/or complexity of creating a policy and determiningwhether these complex instructions violate the policy. Using thetechniques described herein, the PUSH instruction in Version 7 of theARM T32 ISA may be converted into a set of storage operations that eachonly involve a small number of storage locations (e.g., no more than 2storage locations). For example, the first data structure associatedwith a complex instruction may include a pointer that directs the tagprocessor 140 to a new set of simpler, smaller instructions that may beoutput to the rule cache (instead of the complex instruction) along withthe associated metadata for the simpler, smaller instructions. Unrollingcomplex instructions in such a fashion reduces the size and complexityof the metadata associated with the instruction along with thecomputational complexity of determining whether the instructions violatea policy. Thus, these new techniques enable systems to process metadataassociated with these complex instructions with fewer computationalresources.

The inventors have further appreciated that the techniques describedherein to transform instructions for metadata processing may be employedto permit the tag processing hardware 140 handle implicit instructions(e.g., operations for which there is no associated explicit instructionexecuted by the host processor) including those implicit instructionsassociated with changes in context associated with the execution of theinstructions by the host processor 110, such as the host processor 110starting an interrupt service routine (ISR), switching threads, and/ormaking system calls. In these embodiments, the techniques to transforminstructions for metadata processing may be employed to generate newinstruction information and associated metadata that may be provided tothe rule cache that accurately reflects any implicit instructions forthe host processor 110.

When an ISR is triggered, the host processor 110 may automatically storea current value of the interrupt program counter (PC) at a selectedmemory location (e.g., that depends on the particular design of the hostprocessor 110) and load the PC for the ISR as a replacement for theinterrupt PC. As a result, the host processor 110 may change a storagelocation of both the interrupt PC and the PC for the ISR withoutreceiving any explicit instruction to perform such operations. Further,the instruction information received by the tag processing hardware 140may not directly reflect that these storage operations have occurred.The techniques described herein to transform instructions for metadataprocessing may be employed to generate new instruction information andassociated metadata that reflects the performance of these implicitoperations. For example, the first data structure associated with afirst instruction in an ISR may include a pointer to a set of one ormore instructions and associated metadata in other data structures thatreflect the true operations performed by the host processor (e.g., thefirst instruction in the ISR in combination with the instructions tochange the storage locations of the PC for the ISR and the interruptPC). Thus, instruction information and associated metadata provided tothe rule cache capture both the first instruction in the ISR along withthe implicit storage instructions performed by the host processor 110.

It should be appreciated that still yet other techniques may be employedto handle implicit instructions. In some embodiments, the tag processingsystem 140 may purposefully trigger the policy processor 150 to handlethese implicit instructions and, thus, reduce the size of the rule cache144 because the rule cache 144 no longer has to handle these specialsituations. For example, the first data structure may store specialmetadata associated with the first instruction after a context change(e.g., a first instruction in an ISR) for which there is nocorresponding rule stored in the rule cache 144. Thus, the rule cache144 will be unsuccessful in matching the special metadata associatedwith the first instruction after the context change to a rule in therule cache and trigger a rule cache miss. The rule cache miss may causethe tag processing hardware 140 to query the policy processor 150 for aresponse. The policy processor 150 may, in turn, read the specialmetadata and perform a process specific to handling the firstinstruction after the context change. For example, in the case of anISR, the policy processor 150 may perform the appropriate changes toreflect these implicit operations itself (e.g., perform the same swap ofmetadata) and provide the tag processing hardware 140 a single-use ruleapplicable to the first instruction of the ISR. In some embodiments, thepolicy processor 150 may provide the single-use rule to the tagprocessing hardware 140 and then perform the appropriate changes, toreduce the amount of time the tag processing hardware 140 is waiting forthe instruction. Alternatively, or in addition, the policy processor mayperform the appropriate changes to reflect the operations of theinstruction that experienced the rule cache miss, and the single-userule may therefore be a NOP rule

The inventors have further appreciated that the techniques describedherein to transform the instructions for metadata processing may beemployed to create security routines that are processed by the tagprocessing hardware 140 without changing the instructions for a computerprogram executed by the host processor 110. For example, the tagprocessing hardware 140 may supplement the instruction informationassociated with a particular instruction with instruction information(and associated metadata) for the security routine. As a result, thecombined instruction information (and associated metadata) may beprovided as an input to the rule cache 144. Thus, the rule cache 144(and/or other components in the tag processing hardware 140) mayeffectuate the operations associated with the security routine.

When creating security policies for a computer program, it may bedesirable to effect changes in the metadata state of the system atspecific points during execution of the computer program by the hostprocessor 110 (e.g., at interrupt entry, at system calls, at resetvectors, and/or at ordinary function calls). For example, various rulesmay need to be activated (or deactivated) at these points duringexecution of the computer program. Attempting to effectuate thesechanges by associating additional metadata with these instructions maybe unwieldly for the rule cache 144 to process. Further, addinginstructions to the executable program that perform no function (e.g.,NOPs) simply for the purpose of associating metadata with theseinstructions to be processed is problematic because it requiresmodification of the application binaries as well as incurring aperformance penalty (e.g., by forcing the host processor 110 to executethese extra instructions). The techniques described herein may beemployed to enable the tag processing hardware 140 to supplement theinstruction information associated with particular instructions (e.g.,instructions at any of the specific points above) with additionalinstruction information (and associated metadata) associated with asecurity routine.

It should be appreciated that the security routine may perform any of avariety of functions such as: changing security privileges, activatingrules (e.g., in the rule cache 144), and/or deactivating rules (e.g., inthe rule cache 144). For example, the security privileges may be changedat system calls require transferring control from a lower privilegeduser application to a higher privileged operating system. Thus, the tagprocessor 140 may effectuate defined privileges modes on processors thatdon't implement such privilege modes in hardware. Further, for hostprocessors that do implement such privilege modes in hardware, theperformance penalty resulting from saving and/or restoring machinecontexts may be eliminated because the function of implementingprivilege modes may be performed by the tag processor 140. In anotherexample, the security routine may be employed to create finer grainedsecurity policy that elevates privileges on entry to a specific functionand lowers privileges at the completion of the function. Thus, thenotion of privileged system calls may be extended to ordinary softwarefunctions. In yet another example, the security routine may identifyspecific invocations of a library function. In this example, a memorysafety policy may rely on initializing a region of memory and the memoryallocation code uses a memory set function in a shared library. Havingthe security routine run before the function may allow identificationwhen the memory set function is being called to initialize memoryinstead of ordinary use by a computer program.

The inventors have further appreciated that the techniques describedherein to transform the instructions for metadata processing may beemployed to enable metadata processing even if limited information isaccessible from the host processor 110. For example, the instructioninformation received by the tag processing hardware 140 may only includeinstruction information for certain instructions for the host processor(e.g., a filtered representation of the instructions for the hostprocessor). In some embodiments, the instruction information receivedmay only include information regarding branch instructions and omitinformation regarding other non-branch instructions. In theseembodiments, the instruction information associated with branchinstructions may be unrolled into a set of one or more instructions thatcorrespond to an entire instruction path that starts the branchinstruction and ends with the next subsequent branch instruction. Thus,the tag processing hardware 140 may be able provide instructioninformation and associated metadata to the rule cache 144 based on onlya fraction of the instructions for the host processor 110 (e.g., onlythe branch instructions). As a result, the bandwidth requirement betweenthe tag processing hardware 140 and the source of the instructioninformation (e.g., the host processor 110) is substantially reduced.Accordingly, fewer (if any) modifications may need to be made to thehost processor 110 to provide the appropriate information to the tagprocessing hardware 140 to enable metadata processing.

The branch instruction may be unrolled into a set of one or moreinstructions that correspond to an entire instruction path including thebranch instruction in any of a variety of ways. In some embodiments, asoftware application (e.g., a software toolchain) may divide theinstructions for a computer program to be executed by the host processor110 into instruction paths that each start with a first branchinstruction, end with a second branch instruction, and comprise one ormore intermediary instructions between the first and second branchinstructions. Thus, these instruction paths may be the longestcontinuous segments of instructions in the computer program that do notinclude a branch. Instruction information associated with all of theinstructions in the segment (along with the associated metadata) may bestored in data structures that are associated with the first branchinstruction (e.g., prior to execution of the computer program by thehost processor 110). As a result, the tag processing hardware 140 mayunroll a branch instruction into all of the instructions associated withthe instruction path to which the branch instruction corresponds.

It should be appreciated that various techniques, such as static codeanalysis techniques, may be employed to boil down an entire instructionpath into a smaller set of instructions that achieve the same net effect(e.g., are semantically equivalent). This smaller set of instructionsmay be associated with the branch instruction in the data structures inplace of the entire instruction path. Thus, the size of the instructioninformation and associated metadata generated by the tag processinghardware 140 for a given branch instruction may be reduced. For example,the instruction path may be analyzed to determine the operations in theinstruction path. The identified operations in the instruction path may,in turn, be employed to generate a smaller set of instructions based onthe determined operations in the instruction path that achieve the samesemantics. As a result, certain operations that are implemented usingmultiple instructions (such as a sequence of subtraction and shiftoperations) may be simplified into a smaller number of instructions(e.g., a single division operation). Further, one or more instructionsin the instruction path may be removed altogether to form the simplifiedset of instructions in cases where the particular instructions areirrelevant for metadata processing purposes.

The techniques described herein to transform the instructions formetadata processing may be used in combination with other techniques tofurther simplify the process of associating metadata with instructioninformation and/or determining whether instructions violate a policy. Insome embodiments, the tag processing hardware 140 may employ its own ISAthat is separate and distinct from the ISA used by the host processor110. The ISA employed within the tag processing hardware 140 may bespecifically designed for the association and analysis of metadata.Thus, any information in an instruction that is irrelevant to the tagprocessing hardware 140, such as the distinction between opcodes fordifferent mathematical operations, can be genericized or removedaltogether. For example, the differences between the following opcodes:AND, OR, XOR, NOT, ADD, SUBTRACT, MULTIPLY, DIVIDE, REMAINDER, SHIFT maybe inconsequential for the purposes of associating metadata with theseinstructions. Accordingly, all these opcodes may map to a single opcodein the ISA used by the tag processing hardware.

Employing a separate ISA in the tag processing may provide any number ofbenefits over using the ISA employed by the host processor 110throughout the tag processing hardware 140. For example, the tagprocessing hardware 140 may be agnostic to the ISA employed by the hostprocessor 110. Thus, the same (or substantially similar) tag processinghardware 140 may be used with a wide variety of processor types withdifferent ISAs. Further, the policies that are applied by the tagprocessing hardware 140 may be simpler to write, more verifiable, andmore portable across different ISAs because the policies only need to bedesigned to operate on instructions and associated metadata in a singleISA. Still yet further, the hardware area may be reduced by requiring asmaller number of bits to express the instruction opcodes because thenew ISA may have a smaller number of potential opcodes than the host ISA(e.g., because of the simplification of various mathematical opcodes toa single operand). For example, the number of bits required to representthe opcodes may be reduced and, thus, reduce the required memorycapacity to store opcodes. Additionally, in embodiments where the rulecache receives the opcode as an input to determine whether a rule isviolated, the width of the rule cache may be reduced due to the reducednumber of bits required to represent the opcode.

An example implementation of the tag processing system 140 that isconfigured to perform the techniques described herein to transform theinstructions for metadata processing and employ its own ISA that isdifferent from the host ISA is shown in FIG. 3. As shown, the tagprocessing hardware 140 receives third instruction information 301 thatis associated with an instruction in a first ISA 314. The thirdinstruction information 301 may be translated using a translator 304from the first ISA 314 to a second, different ISA 316 to generate firstinstruction information 303. The tagging component 306 may use theinformation in the tag map table 142 and/or information stored in thefirst, second, and/or third data structures 308, 310, 312 to identifysecond instruction information 305 and associated metadata 307. Thesecond instruction information 305 and associated metadata 307 output bythe tagging component 306 may, in turn, be employed by the tagprocessing hardware 140 to determine whether an instruction violates apolicy (e.g., using any of the techniques described above).

The third instruction information 301 may include information indicativeof an instruction for a host processor in the first ISA 314. The thirdinstruction information 301 may, for example, comprise one or more ofthe following pieces of information: (1) an instruction type (e.g.,opcode), (2) an address where the instruction is stored, (3) one or morememory addresses referenced by the instruction, (4) one or more registeridentifiers, (5) the instruction itself or any component thereof, and/or(6) signals to indicate if a conditional instruction was executed ornot. The particular way by which the third instruction information 110is received may vary based on the particular implementation.

In some embodiments, the third instruction information 301 may compriseinformation indicative of the instructions output by the finalprocessing stage of the host processor. Thus, the third instructioninformation 301 may only contain information regarding retiredinstructions (e.g., instructions that have been fully executed by thehost processor and were needed for execution of a program flow). Inthese embodiments, the third instruction information 301 may be directlyprovided to the translator 304 for translation to generate the firstinstruction information 303.

In some embodiments, the third instruction information 301 may compriseinformation regarding instructions output by an intermediate stage ofthe host processor (e.g., a stage earlier than the final stage). Thus,the third instruction information 301 may contain information regardingboth instructions necessary for the execution of the computer program(e.g., those instructions that will become retired instructions) andthose instructions that are not necessary for the execution of thecomputer program (e.g., those instructions that will not become retiredinstructions). In these embodiments, the tag processing hardware 140 mayimplement a mechanism to separate the information associated withinstructions that will become retired instructions from that informationassociated with instructions that are never retired. Thus, only theinformation associated with instructions that will become retiredinstructions (e.g., instructions that will be fully executed) may beprovided to the translator 304 while the information regarding theinstructions that will not become retired (e.g., instructions that willnot be fully executed) may be ignored. Any of a variety of techniquesmay be employed to separate the instruction information. For example, apair of First-In-First-Out (FIFO) queues may be employed where a firstFIFO queue may capture the received instructions from the hostprocessor, including a mix of some instructions that will be retired andsome instructions that will never be retired, as well as a correspondingaddress where each of those instructions are stored. The second FIFOqueue may capture the addresses of the instructions that have beenretired by the host processor. Once both FIFO queues are non-empty, thetag processing hardware 140 may pop off instructions in the first FIFOuntil an instruction address in the first FIFO queue matches aninstruction address in the second FIFO queue (e.g., indicating that aparticular instruction stored in the first FIFO queue has been retired).The matching instructions in the first FIFO queue may, in turn, beprovided to the translator 304 for translation into the firstinstruction information 303.

In some embodiments, the third instruction information 301 may beobtained by snooping the read interface of the host processor'sinstruction cache and maintaining a mirror image of the cache (e.g., amirror cache) to fetch instructions based on instruction addressesreceived from the host processor. In these embodiments, the tagprocessing hardware 140 may maintain a mirror of the host processor's L1cache by snooping the read interface of the L1 cache. For everyinstruction the L1 cache reads in, the tag processing hardware 140 mayprovide the corresponding instruction contained in the mirror cache asan input to the translator 304 for translation into the firstinstruction information 303. In order to account for the pipeline delayof the host processor and/or the delay in receiving information from thehost processor, the writes into the mirror cache may be delayed by thesame number of cycles. For example, the instruction that causes the L1cache to do a refill action may also cause the eviction (and/oroverwrite) of a line in the L1 cache containing recently consumedinstructions. If the tag processing hardware 140 mirrors the L1 cache inreal time, the tag processing hardware 140 may evict the line containingthe instruction(s) from the mirror cache that have yet to flow out ofthe host processor (due to the pipeline delay in the host processor).If, however, the tag processing hardware 140 waits for a number ofinstructions equal to the number of stages in the host processor to flowout of the host processor before updating the mirror cache, then all thelines in the mirror cache match the state of the L1 cache at the timethe instruction fetch occurred in the host processor. Due to thepossibility of the host L1 cache and the mirrored L1 cache havingdifferent eviction policies, a mechanism may also be provided forreading the instruction bits from main memory when the mirror cacheexperiences a miss (e.g., caused by a program flow change event to codenot cached, linear code that exceeds the size of the cache, etc.).

In some embodiments, the third instruction information 301 may beobtained by the tag processing hardware 140 using the instructionaddress received from the host processor to re-fetch the instructionsfrom main memory. In these embodiments, the tag processing hardware 140may read the instruction from main memory using the instruction addressassociated with the instruction received from, for example, the hostprocessor. Thus, the tag processing hardware 140 may not need tomaintain a mirror image of the L1 cache of the host processor. However,in some embodiments, the tag processing hardware 140 may utilize amirror cache that is a mirror image of the L1 cache. Employing a mirrorcache may advantageously prevent memory fetches for each line ofinstructions occurring twice in close temporal proximity. Thus, thepower consumption of the hardware and memory bandwidth congestion may bereduced. Unlike the snoop method discussed above, this method may notrequire the mirror cache in the tag processing hardware 140 to be thesame size and shape as the host processor's L1 instruction cache. Insome embodiments, this method may utilize snooping of the host's L1 readinterface to populate a buffer of recently fetched lines such thatmisses in the mirror cache of the tag processing hardware 140 may thenhit one of these buffered lines. In some embodiments, in this method,the instruction data stored in the mirror cache in the tag processinghardware 140 may be, for example, data either before or after goingthrough the ISA translation. Translating the instructions in the mirrorcache may advantageously reduce the size of the instructions (e.g.,because the translated instructions may be smaller than hostinstructions), which may reduce the size of the mirror cache as well aspower.

As discussed above, the tag processing hardware 140 may employ its ownISA (e.g., the second ISA 316) that is different from the ISA employedby the host processor (e.g., the first ISA 314). Accordingly, the tagprocessing hardware 140 may include components to translate the thirdinstruction information 301 that is in the first ISA to correspondingfirst instruction information 303 that is in the second ISA. Thistranslation may be performed, at least in part, by the translator 304,which may be implemented as a hardware translator, a softwaretranslator, or any combination thereof.

The particular method employed by the translator 304 to translate thethird instruction information 301 to the first instruction information303 may vary based on the particular implementation. In someembodiments, the translator 304 may perform the translation dynamicallyduring the run-time of the tag processing hardware 140. In theseembodiments, the translator 304 may employ a set of known relationshipsbetween the first and second ISAs 314 and 316, respectively, (e.g., inthe form of a look-up table) to perform this conversion. For example,the translator 304 may use mappings between opcodes in the first ISA andopcodes in the second ISA (e.g., the opcodes ADD and SUBTRACT in thefirst ISA 314 map to the opcode MATH OPERATION in the second ISA 316) toconvert the opcode portion of the instruction from the first ISA 314 tothe second ISA 316. In other embodiments, the translation of theinstructions in a computer program between the first and second ISAs 314and 316, respectively, may be performed before execution of the tagprocessing hardware 140 and stored in memory. In these embodiments, thetranslator 304 may retrieve the pre-translated instructions in thesecond ISA 316 from memory that match the input instructions in thefirst ISA 314. As a result, the complexity of the translator 304 may bereduced.

In some embodiments, certain instructions in the first ISA 314 may notneatly map to a single instruction in the second ISA 316. Instead, theseinstructions in the first ISA 314 may map to a plurality of instructionsin the second ISA 316 (e.g., these instructions in the first ISA 314need to be unrolled into multiple simpler instructions). In theseembodiments, the translator 304 may not fully translate instructions inthe first ISA 314 that correspond to multiple instructions in the secondISA 316. The translator 304 may, instead, provide the untranslated (orpartially translated) first instruction information 303 to the taggingcomponent 306 that may, in turn, be used by the tagging component 306 togenerate the second instruction information 305 that is fullytranslated. For example, in response to the third instructioninformation 301 mapping to multiple instructions in the second ISA 316,the translator 304 may simply pass-through the third instructioninformation 301 in the first ISA 314 to the tagging component 306 as thefirst instruction information 303. Alternatively, the translator 304 mayoutput a single instruction (e.g., a first instruction) in the set ofinstructions in the second ISA 316 to which the received thirdinstruction information 301 corresponds as the first instructioninformation 303. In this example, the translator 304 may also output aflag to notify the tagging component 306 that the translation isincomplete.

The distinction between instructions that need to be transformed may bedetermined prior to run-time of the tag processing hardware 140. In someembodiments, a software application (e.g., a software toolchain) mayidentify instructions in a computer program to be executed by the hostprocessor that need to be transformed. In these embodiments, thesoftware application may generate an indication of which instructions inthe computer program need to be transformed and store this indication inmetadata memory (e.g., metadata memory 125). For example, the softwareapplication may generate a first data structure 308 for each instructionthat includes a flag indicative of whether a given instruction needs tobe transformed. If the instruction does not need to be transformed(shown in FIG. 3 as state “0”), the flag in the first data structure 308may be accompanied by the metadata to associated with the respectiveinstruction (e.g., the instruction to which the particular first datastructure 308 corresponds). If the instruction does need to betransformed (shown in FIG. 3 as state “1”), the flag in the first datastructure 308 may be accompanied by pointer(s) to other datastructure(s) that include new instruction information (shown as thirddata structure 312) and the associated metadata (shown as second datastructure 310). The first data structure 308 may, in some embodiments,only include a pointer to one of the second and third data structures310 and 312. In these embodiments, the remaining data structure (e.g.,the data structure for which there is no explicit pointer to in thefirst data structure 308) may be located a fixed offset in memory awayfrom the other data structure (e.g., the data structure for which thereis an explicit pointer to in the first data structure 308). Thereby, oneof data structures 310 and 312 may be found using a pointer in the firstdata structure 308 and the remaining data structure may be found byreading another memory location that is a fixed distance away from thetarget of the pointer. In other embodiments, the first data structure308 may include pointers to both the second data structure 310 and thethird data structure 312.

It should be appreciated that these second and third data structures 310and 312, respectively, may further include pointers to still yet otherdata structures if additional instruction information and/or metadata isnecessary. For example, the third data structure 312 may include someinstruction information and a pointer to another data structure withadditional instruction information. In this example, the flag in thethird data structure 312 may be set to indicate that additionalinformation is available (e.g., the flag may be in state “1” instead of“0”). Similarly, the second data structure 310 may include some metadataand a pointer to another data structure with additional metadata.

In some embodiments, the stored information regarding whether aparticular instruction needs to be transformed may be employed by thetagging component 306 to generate second instruction information 305that is fully translated in the second ISA 316 (e.g., is transformed asappropriate) and associated metadata 307. In these embodiments, thetagging component 306 may locate the first data structure 308 associatedwith the first instruction information 303. For example, the taggingcomponent 306 may identify an entry in the tag map table 142 thatcorresponds to the first instruction information 303 and include eithera pointer to the location of the relevant first data structure 308 orthe relevant first data structure 308 itself. Once the tagging component306 has identified the relevant first data structure 308, the taggingcomponent 306 may read the flag contained in the first data structure308 to determine whether the first instruction information 303 needs tothe transformed. If the flag indicates that the first instructioninformation 303 does not need to be transformed, the tagging component306 may retrieve the metadata associated with the first instructioninformation 303 from the first data structure 308 and output themetadata as the metadata 307. Further, the tagging component 306 maydirectly output the first instruction information 303 as the secondinstruction information 305. If the flag indicates that the firstinstruction information 303 does need to be transformed, the taggingcomponent 306 may read the pointer included in the first data structure308 to other data structures that include in the new instructioninformation (shown as the third data structure 312) and the metadata toassociated with the new instructions (shown as the second data structure310). Further, the tagging component 306 may output the new instructioninformation in the third data structure 312 as the second instructioninformation 305 and output the metadata in the second data structure 310as the metadata 307.

It should be appreciated that various modifications may be made to theparticular implementation of the tag processing hardware 140 shown inFIG. 3 without departing from the scope of the present disclosure. Forexample, the translator 304 and the tagging component 306 may becombined into a single component. In this example, the tag map table 142may contain information that describes the relationships between thethird instruction information 301 and the first data structure 308(e.g., the tag map table 142 may comprise entries that match the thirdinstruction information 301 to storage locations of corresponding firstdata structures). Further, the first data structure 308 may include apointer to other data structures that comprises new instructioninformation that is a pre-translated (and/or unrolled) version of thethird instruction 301 in addition to metadata associated with the newinstruction information. Thus, the combined translator and taggingcomponent may access the first data structure 308 to identify a pointerto the storage location of instruction information that is translatedinto the second ISA and the associated metadata. The instructioninformation may, in turn, be provided as the second instructioninformation 305 and the associated metadata may be output as metadata307.

FIG. 6 shows an illustrative hardware system 600 for enforcing policiesusing a policy engine, in accordance with some embodiments. A computingsystem can include hardware system 600, which can be configured toenforce security policies as described herein. This hardware system caninclude host processor 110, a policy engine 610, and an interlock 112.These components can interoperate to enforce the security policies. Thehost processor 110 can execute an instruction and provide instructioninformation to the policy engine 610 and the result of the executedinstruction to the interlock 112. The policy engine 610 can determinewhether the executed instruction is allowable according to one or moresecurity policies using the instruction information. The interlock 112can buffer the result of the executed instruction until an indication isreceived from the policy engine 610 that the instruction was allowable.The interlock 112 can then release the result of the executedinstruction for use by the remainder of the computer system.

The policy engine 610 can determine whether the executed instruction isallowable based on metadata associated with the instruction. Themetadata may concern memory locations or entities such as hardwarecomponents or software component of the computing system. Multiplerefinements are disclosed herein to increase the efficiency andflexibility of this architecture.

In particular, the inventors have recognized and appreciated thatconfiguring the policy engine 610 to transform instructions receivedfrom the host processor 110 into one or more other instructions canprovide benefits including a reduction in the complexity of the policyengine 610 and provide opportunities to speed policy evaluation.

The inventors have also recognized and appreciated that configuring thepolicy engine 610 to add inserted instructions to the policy evaluationpipeline can provide benefits including an ability to address inferredhost processor 110 actions and provide further support for comprehensivesecurity policies.

The inventors have further recognized and appreciated that configuringthe policy engine 610 to transform instructions received from the hostprocessor 110 into an intermediate representation can increase theportability and flexibility of the envisioned systems and methods. Insuch embodiments, the translation from host processor 110 instructionsto intermediate representations can be addressed and optimizedindependently from the evaluation of security policies based on theintermediate representations.

The inventors have further recognized and appreciated that the disclosedpolicy engine 610 may be realized using hardware (e.g. an applicationspecific integrated circuit, or a collection of discrete components)alone or combination with firmware (e.g., a field-programmable gatearray or programmable read-only memory programmed to operate with aparticular host processor and/or interlock) and/or software (e.g., apolicy processor configured to implement one or more policiesimplemented in software). Though described below for convenience withrespect to tag processing hardware 140 and a policy processor 150, thisdescription is not intended to be limiting.

Policy engine 610 can be configured to ensure that instructions beingexecuted by the host processor 110 comply with one or more policies.Policy engine 610 can include any suitable combination of hardware,firmware, and/or software suitable for performing this task. Forexample, policy engine 610 can include tag processing hardware 140 andpolicy processor 150. In some embodiments, tag processing hardware 140may be configured for rapid execution of policy decisions. In variousembodiments, policy processor 150 may be configured to addressspecial-case or complicated policy decisions (e.g., those involvingfunction calls or interrupt handling) and/or initial policy decisions(e.g., a first evaluation of a policy with respect to a particularinstruction, set of instructions, memory location, and/or entity).

FIG. 4 shows an illustrative policy enforcement process 400 performed bypolicy engine 610 using transformed instructions. Process 400 caninclude the acts of receiving first instruction information associatedwith at least one first instruction, transforming the first instructioninformation into second instruction information associated with at leastone second instruction, determining the at least one first instructionis allowable according to a policy using second metadata correspondingto the at least one second instruction, an providing an indication tothe interlock. This indication may instruct the interlock to provide aqueued result of executing the at least one first instruction toremainder of the computing system. In this manner, the allowability ofthe at least one first instructions can be determined using the metadataassociated with the at least one second instructions.

In some embodiments, the at least one second instructions may comprisesimpler instructions (or instructions from a more limited set ofinstructions) that are equivalent to the at least one first instruction.Configuring policy engine 610 to evaluate the at least one secondinstruction can allow for a simpler policy engine (as the secondinstructions may be simpler or fall within a more limited set ofinstructions). In various embodiments, a second instruction maycorrespond to multiple first instructions, allowing policy engine 610 torealize efficiencies in evaluating policies.

In act 410, policy engine 610 can receive first instruction informationassociated with the at least one first instructions. As describedherein, the first instruction information can include any informationindicative of the instruction or any component thereof such as theentire instruction itself, an instruction type (e.g., opcode) of theinstruction, an address where the instruction is stored, registers whereoperands are stored, and/or one or more memory addresses referenced bythe instruction. This first instruction information can be receivedaccording to any of the approaches described herein.

In act 420, policy engine 610 can transform the first instructioninformation into second instruction information associated with at leastone second instruction. In some embodiments, the at least one secondinstruction can include instructions equivalent to the firstinstruction. In some instances, the one or more first instruction may beequivalent to one or more second instructions when the one or more firstinstruction is convertible into a set of second instructions. A PUSHinstruction in Version 7 of the ARM T32 ISA, for example, can beconverted into set of storage operations that each only involve a smallnumber of storage locations (e.g., no more than 2 storage locations). Aset of addition instructions, as an additional example, can be convertedinto a multiplication instruction. In various instances, the one or morefirst instruction may be equivalent to the plurality of instructionswhen execution of the at least one first instruction and the pluralityof instructions, by the host processor with the same operands, generatesthe same output. In this manner, under execution by host processor 110,the first instruction and the plurality of instructions may have thesame input-output relationship. For example, the at least one firstinstruction or the plurality of instructions can include instructionsthat do not affect the state of the computing system. In some instances,the at least one first instruction and the plurality of instructions canaffect the same entities and/or memory locations. For example, multipleoperations affecting a memory location, entity, or the like may beequivalent to a single operation affecting the same memory location,entity, or the like, as policy engine 610 may address whetherinstructions may be executed, rather than the values generated byexecuting the instructions. Evaluating the single operation in place ofthe multiple operations may increase the efficiency and speed of policyengine 610.

In some embodiments, the second instruction information can include anyinformation indicative of the at least one second instructions or anycomponent thereof such as the at least one second instructions itself,an instruction type (e.g., opcode) of the at least one secondinstructions, an address where the at least one second instructions isstored, registers where operands are stored, and/or one or more memoryaddresses referenced by the at least one second instructions.

In various embodiments, policy engine 610 can obtain the secondinstruction information using the first instruction information. Forexample, policy engine 610 can obtain first metadata associated with theat least one first instruction, using at least one of the approachesdescribed herein. The first metadata can indicate a location of thesecond instruction information and/or metadata. For example, the firstmetadata can include at least one pointer to at least one datastructure. The at least one data structure can contain the secondinstruction information (which may correspond to a plurality ofinstructions equivalent to the at least one first instruction). In someembodiments, policy engine 610 can use the second instructioninformation to obtain the metadata associated with the at least onesecond instruction. In various embodiments, the at least one datastructure can include the metadata for the at least one secondinstruction.

In some embodiments, the at least one first instruction can be, or caninclude, a first branch instruction. As described above, the hostprocessor may be configured to provide only include informationregarding branch instructions and omit information regarding othernon-branch instructions. In such embodiments, the at least one secondinstruction can include an instruction path including the first branchinstruction. Alternatively, the at least one second instruction caninclude a set of instructions semantically equivalent to the instructionpath. The semantically equivalent instructions may omit one or moreinstructions in the instruction path. Furthermore, the semanticallyequivalent instructions may replace one or more instructions in theinstruction path corresponding to a single operation with an instructionrepresenting that operation. Policy engine 610 can obtain the secondinstruction information for the instruction path using the firstinstruction information. For example, policy engine 610 can use thefirst instruction information to obtain first metadata corresponding tothe branch instruction. The first metadata can indicate a location ofinstruction information and/or metadata for the instruction path. Forexample, the first metadata can include a pointer indicating a locationof instruction information and/or metadata for the instruction path.

In act 430, policy engine 610 can determine the at least one firstinstruction is allowable according to a policy using second metadatacorresponding to the at least one second instruction. This evaluationmay proceed as described elsewhere herein. In act 440, policy engine 610can provide an indication to an interlock. The interlock may thenrelease the result(s) of the at least one first instruction to theremainder of the computer system.

FIG. 5 shows an illustrative policy enforcement process 500 by policyengine 610 using added instructions. Process 500 can include the acts ofreceiving first instruction information associated with at least onefirst instruction, obtaining second metadata and second instructioninformation associated with at least one second instruction, generatingthird metadata using at least one of the second instruction informationand the second metadata, and updating policy metadata using the thirdmetadata. Once the policy metadata has been updated, policy engine 610may determine whether subsequent instructions executed by the hostprocessor are allowable according to policies based on the updatedpolicy metadata. When such instructions are allowable, policy engine 610can provide an indication of allowability to an interlock. The interlockcan then provide a queued result of executing the subsequentinstructions to the remainder of the system.

In act 510, policy engine 610 may receive first instruction informationassociated with at least one first instruction. As described herein, thefirst instruction information can include any information indicative ofthe instruction or any component thereof such as the entire instructionitself, an instruction type (e.g., opcode) of the instruction, anaddress where the instruction is stored, registers where operands arestored, and/or one or more memory addresses referenced by theinstruction. This first instruction information can be receivedaccording to any of the approaches described herein.

In some embodiments, the at least one first instruction can beassociated with a change in host processor context. In some instancesthis change in host processor context can correspond to initiation of aninterrupt service routine, thread switching, exception, or a systemcall. For example, the first instruction can be an initial instructionin an interrupt service routine, or concern an address within aninterrupt vector table.

In act 520, policy engine 610 may obtain second metadata and secondinstruction information associated with at least one second instruction.The at least one second instruction may include one or more insertedinstructions. The inclusion of the inserted instructions may cause theat least one second instruction to become semantically different fromthe at least one first instruction. For example, while the insertedinstruction may correspond to instructions that could be executed byhost processor 110, security engine 610 may be configured to obtain theinserted instructions regardless of whether they were included in the atleast one first instruction, in order to effectuate an update in themetadata. For example, the at least one second instruction may beobtained to effectuate an update to the at least one of the tag maptable, the tag register file, or the metadata memory. This update canensure that the metadata is, or remains, consistent with one or morepolicies enforced by policy engine 150.

In various embodiments, the at least one second instruction can includea set of instructions corresponding to operations performed by the hostprocessor when changing context. These instructions may be predefinedand may depend on a type of the host processor. For example, when thehost processor executes a particular type of context change (e.g.,servicing an interrupt) the host processor may perform a standard set ofoperations that depend on the architecture of the host processor. Policyengine 610 may be configured to infer the performance of theseoperations based on the receipt of the at least one first instruction.To accurately reflect to the state of the computing device, policyengine 610 may therefore add additional instructions to the policyevaluation pipeline, such that the tag map table, the tag register file,and/or the metadata memory correctly reflect the state of the system.

In some embodiments, tag processing hardware 140 may use the received atleast one instruction to obtain the second metadata and secondinstruction information. In some instances, tag processing hardware 140may obtain the first metadata using the received first instructioninformation. The first metadata may indicate a location of the secondinstruction information and the second metadata. For example, the firstmetadata may include at least one pointer to at least one datastructure. The at least one data structure may contain the secondinstruction information. In some instances, the tag processing hardware140 may be configured to use the second instruction information toobtain the second metadata. In various instances, the at least one datastructure may contain the second metadata.

In act 530, policy engine 610 may generate update metadata using atleast one of the second instruction information and second metadata. Forexample, the tag processing hardware 140 can be configured to use a rulecache 144 to map the second metadata to update metadata. As anadditional example, policy processor 150 can be configured to generatethe update metadata by applying one or more policies to the secondmetadata. For example, tag processing hardware 140 may query policyprocessor 150 for authorization to allow the first instruction. Asdiscussed herein, the tag processing hardware 140 can be configured tomaintain a rule cache. This rule cache may not include an entry for thefirst instruction, causing tag processing hardware 140 to query thepolicy processor 150 for authorization to allow the first instruction.Policy processor 150 can be configured to receive the query. In responseto the query, policy processor 150 can determine the update metadata.

In some instances, policy processor 150 can be configured to provide asingle-use rule that evaluates to the update metadata to tag processinghardware 140. Tag processing hardware 140 can be configured to receivethat single-use rule. As the rule is single use, tag processing hardware140 may not store the rule in the rule cache, but may evaluate thesingle-use rule to generate the update metadata. Alternatively, the tagprocessing hardware 140 may store the single-use rule in the rule cache,and be configured to remove or invalidate that rule from the rule cachewhen it is used.

In act 540, policy engine 610 can update a metadata storage locationusing the generated update metadata. In some embodiments, tag processinghardware 140 may update the metadata storage location using thegenerated update metadata. In various embodiments, the metadata storagelocation can include at least one of a tag map table, tag register file,or metadata memory. For example, tag processing hardware 140 may writenew metadata to a location in the metadata memory; or create, modify, ordelete one or more entries in the tag map table and/or the tag registerfile. In various instances, policy processor 150 can be configured toupdate the at least one of the tag map table, the tag register file, orthe metadata memory using the generated update metadata. For example,policy processor 150 can directly affect the state of the tag processinghardware 140 by directly updating the tag map table and/or the tagregister file. As an additional example, policy processor 150 can writeupdated metadata to a location in metadata memory, or cause tagprocessing hardware 140 to write updated metadata to the location inmetadata memory by directly changing memory or register values in tagprocessing hardware 140.

In some embodiments, the update metadata concerns a security routine.For example, the security routine may effectuate software-definedprivileges modes by changing security privileges in response to systemcalls and/or non-system function calls. For example, when a system calloccurs, the update metadata may enact a higher privilege levelappropriate for a system call. Once the system call ends, the updatemetadata may enact a return to a lower privilege level appropriate for auser. These changes in privilege level may be implemented by updatingthe at least one of the tag map table, tag register file, or metadatamemory using the generated update metadata.

In various embodiments, policy engine 610 may implement a stack policy.This stack policy may specify read-only access to certain locations inthe call stack during a function call. For example, instructionsassociated with a body of a function may have read-only access duringthe function call to locations in the call stack containing valuesgenerated by calling conventions for the function (e.g., the functionprologue and function epilogue). Policy engine 610 may implement thispolicy by labeling the function prologue and function epilogue with ametadata tag (e.g., a label of “frame”) during the function call. Policyengine 610 may be configure to refuse writes or destructive readstargeting memory locations associated with this metadata tag during thefunction call. When a first instruction indicates completion of the callto the function, metadata associated with the first instruction maydirect policy engine 610 to obtain at least one second instructioninformation and second metadata, wherein the at least one secondinstruction information and second metadata causes the policy engine 610to remove metadata marking addresses as read-only from the location inthe call stack. This update may disassociate the metadata tag from thelocations previously containing the function prologue and functionepilogue.

In act 550, policy engine 610 can be configured to determine whethersubsequently executed instructions are allowable according to policiesbased on the updated policy metadata. In some instances, once themetadata has been updated in act 540, policy engine 610 mayautomatically rely on the updated metadata when making subsequentallowability determinations. In act 560, when indicated, policy engine610 can provide an indication to interlock 112 to release the results ofsuch subsequently executed and allowed instructions.

Illustrative Computer

FIG. 7 shows, schematically, an illustrative computer 700 on which anyaspect of the present disclosure may be implemented.

In the embodiment shown in FIG. 7, the computer 700 includes aprocessing unit 701 having one or more processors and a non-transitorycomputer-readable storage medium 702 that may include, for example,volatile and/or non-volatile memory. The memory 702 may store one ormore instructions to program the processing unit 701 to perform any ofthe functions described herein. The computer 700 may also include othertypes of non-transitory computer-readable medium, such as storage 705(e.g., one or more disk drives) in addition to the system memory 702.The storage 705 may also store one or more application programs and/orresources used by application programs (e.g., software libraries), whichmay be loaded into the memory 702.

The computer 700 may have one or more input devices and/or outputdevices, such as devices 706 and 707 illustrated in FIG. 7. Thesedevices may be used, for instance, to present a user interface. Examplesof output devices that may be used to provide a user interface includeprinters and display screens for visual presentation of output, andspeakers and other sound generating devices for audible presentation ofoutput. Examples of input devices that may be used for a user interfaceinclude keyboards and pointing devices (e.g., mice, touch pads, anddigitizing tablets). As another example, the input devices 707 mayinclude a microphone for capturing audio signals, and the output devices706 may include a display screen for visually rendering, and/or aspeaker for audibly rendering, recognized text.

In the example shown in FIG. 7, the computer 700 also includes one ormore network interfaces (e.g., the network interface 710) to enablecommunication via various networks (e.g., the network 720). Examples ofnetworks include a local area network (e.g., an enterprise network) anda wide area network (e.g., the Internet). Such networks may be based onany suitable technology and operate according to any suitable protocol,and may include wireless networks and/or wired networks (e.g., fiberoptic networks).

Furthermore, the present technology can be embodied in the followingconfigurations:

(1) A system, comprising a policy engine configured to receive firstinstruction information associated with at least one first instructionexecuted by a host processor; transform the first instructioninformation into second instruction information associated with at leastone second instruction; determine, using second metadata correspondingto the at least one second instruction, whether the at least one firstinstruction is allowable according to a policy.

(2) The system of (1), wherein policy engine is further configured toprovide, in response to determining that the at least one firstinstruction is allowable to an interlock, an indication to release aqueued result of executing the at least one first instruction.

(3) The system of (1) or (2), wherein transforming the first instructioninformation into second instruction information comprises: obtainingfirst metadata associated with the at least one first instruction usingthe first instruction information; obtaining, using the first metadata,instruction information and metadata for a plurality of instructions,the plurality of instructions equivalent to the at least one firstinstruction; and wherein the second metadata comprises metadata for theplurality of instructions.

(4) The system of (3), wherein the first metadata comprises at least onepointer to at least one data structure comprising the instructioninformation for the plurality of instructions; and the metadata for theplurality of instructions.

(5) The system of (3) or (4), wherein the plurality of instructions isequivalent to the at least one first instruction when the at least onefirst instruction is convertible into the plurality of instructions.

(6) The system of (3) or (4), wherein the plurality of instructions isequivalent to the at least one first instruction when a first executionof the at least one first instruction and a second execution of theplurality of instructions have the same input-output behavior.

(7) The system of (3) or (4), wherein the plurality of instructions isequivalent to the at least one first instruction when a first executionof the at least one first instruction and a second execution of theplurality of instructions affect the values of the same entities and/ormemory locations.

(8) The system of any of (1) to (7), wherein the at least one firstinstruction comprises a first branch instruction; and the at least onesecond instruction comprises an instruction path including the firstbranch instruction.

(9) The system of any of (1) to (7), wherein the at least one firstinstruction comprises a first branch instruction; and the at least onesecond instruction comprises a set of instructions that omits one ormore instructions in the instruction path; and/or replaces one or moreinstructions in the instruction path corresponding to a single operationwith an instruction representing the operation.

(10) A system comprising a policy engine configured to receive firstinstruction information associated with at least one first instructionexecuted by a host processor; in response to receiving the firstinstruction information obtain: second instruction informationassociated with at least one second instruction; and second metadataassociated with the at least one second instruction; generate thirdmetadata using at least one of the second instruction information orsecond metadata; update metadata storage location using the thirdmetadata; and determine whether at least one instruction executed by ahost processor is allowable according to at least one policy.

(11) The system of (10), wherein the metadata storage location comprisesat least one of a tag map table, tag register file, or metadata memory.

(12) The system of (10) or (11), wherein the policy engine is furtherconfigured to provide, to an interlock in response to the determination,an indication to release a queued result of executing the at least oneinstruction.

(13) The system of any of (10) to (12), wherein the at least one firstinstruction is associated with a change in host processor context; andthe at least one second instruction comprises a set of instructionscorresponding to operations performed by the host processor whenchanging context.

(14) The system of (13), wherein the change in host processor contextcorresponds to initiation of an interrupt service routine, threadswitching, exception or a system call.

(15) The system of (13) or (14), wherein the set of instructions furthercorresponds to a type of the host processor.

(16) The system of any of (10) to (15), wherein the policy enginecomprises tag processing hardware configured to obtain first metadatausing the first instruction information, the first metadata comprisingat least one pointer to at least one data structure containing thesecond instruction information and the second metadata.

(17) The system of any of (10) to (15), wherein the policy enginecomprises tag processing hardware configured to receive the firstinstruction information; and in response to receiving the firstinstruction information, query to the policy processor to validate thefirst instruction; and the policy engine comprises a policy processorconfigured to receive the query; and determine the third metadata inresponse to the query.

(18) The system of (17), wherein the policy processor is furtherconfigured to provide a single-use rule that evaluates to the updatemetadata to the tag processing hardware; and the tag processing hardwareis further configured to receive the single-use rule; evaluate thesingle-use rule to generate the update metadata; and update the at leastone of the tag map table, the tag register file, or the metadata memoryusing the generated update metadata.

(19) The system of (17), wherein the policy processor is furtherconfigured to update the metadata storage location.

(20) The system of any of (10) to (19), wherein the at least one secondinstruction comprises a inserted instruction obtained to effectuate theupdate of the metadata storage location.

(21) The system of (20), wherein the inserted instruction causes the atleast one second instruction to semantically differ from the at leastone first instruction.

(22) The system of (20) or (21), wherein the third metadata concerns asecurity routine; and updating the at least one of the tag map table,tag register file, or metadata memory using the generated third metadataimplements the security routine.

(23) The system of (22), wherein the security routine effectuatessoftware-defined privileges modes by changing security privileges inresponse to system calls and/or non-system function calls.

(24) The system of (20) or (21), wherein the policy engine implements astack policy specifying read-only access to locations in a call stackassociated with a metadata tag by instructions within a body of afunction during calls to the function; a first instruction indicatescompletion of a call to the function; and updating the at least one ofthe tag map table, tag register file, or metadata memory using thegenerated update metadata comprises disassociating the locations in thecall stack with the metadata tag.

(25) The system of (24), wherein the locations in the call stack containdata generated by calling conventions for the function.

(26) A system, comprising a policy engine configured to receiveinstruction information associated with a first instruction in a hostInstruction Set Architecture (ISA) used by a host processor; generate atranslation of the instruction information, the translation not in thehost ISA; obtain metadata using an address of the first instruction; anddetermine, using the metadata, whether the at least one firstinstruction is allowable according to a policy.

(27) The system of (26), wherein the at least one of tag processinghardware or a policy processor is further configured to provide, to aninterlock, an indication to provide a queued result of executing the atleast one first instruction.

(28) The system of (26) or (27), wherein the translation of theinstruction information is in a policy engine ISA.

(29) The system of (26) or (27), wherein generating the translation ofthe instruction information comprises converting the first instructionin the host ISA to a second instruction in the policy engine ISAaccording to a predetermined mapping.

(30) The system of (29), wherein the predetermined mapping isimplemented using a field-programmable gate array or dedicated logiccircuits.

(31) The system of (26) or (27), wherein generating the translation ofthe instruction information comprises identifying at least one datastructure comprising at least one instruction in the policy engine ISAand the metadata; and the translation of the instruction informationcomprises the at least one instruction in a policy engine ISA.

Having thus described several aspects of at least one embodiment, it isto be appreciated that various alterations, modifications, andimprovements will readily occur to those skilled in the art. Suchalterations, modifications, and improvements are intended to be withinthe spirit and scope of the present disclosure. Accordingly, theforegoing descriptions and drawings are by way of example only.

The above-described embodiments of the present disclosure can beimplemented in any of numerous ways. For example, the embodiments may beimplemented using hardware, software, or a combination thereof. Whenimplemented in software, the software code may be executed on anysuitable processor or collection of processors, whether provided in asingle computer, or distributed among multiple computers.

Also, the various methods or processes outlined herein may be coded assoftware that is executable on one or more processors running any one ofa variety of operating systems or platforms. Such software may bewritten using any of a number of suitable programming languages and/orprogramming tools, including scripting languages and/or scripting tools.In some instances, such software may be compiled as executable machinelanguage code or intermediate code that is executed on a framework orvirtual machine. Additionally, or alternatively, such software may beinterpreted.

The techniques disclosed herein may be embodied as a non-transitorycomputer-readable medium (or multiple computer-readable media) (e.g., acomputer memory, one or more floppy discs, compact discs, optical discs,magnetic tapes, flash memories, circuit configurations in FieldProgrammable Gate Arrays or other semiconductor devices, or othernon-transitory, tangible computer storage medium) encoded with one ormore programs that, when executed on one or more processors, performmethods that implement the various embodiments of the present disclosurediscussed above. The computer-readable medium or media may betransportable, such that the program or programs stored thereon may beloaded onto one or more different computers or other processors toimplement various aspects of the present disclosure as discussed above.

The terms “program” or “software” are used herein to refer to any typeof computer code or set of computer-executable instructions that may beemployed to program one or more processors to implement various aspectsof the present disclosure as discussed above. Moreover, it should beappreciated that according to one aspect of this embodiment, one or morecomputer programs that, when executed, perform methods of the presentdisclosure need not reside on a single computer or processor, but may bedistributed in a modular fashion amongst a number of different computersor processors to implement various aspects of the present disclosure.

Computer-executable instructions may be in many forms, such as programmodules, executed by one or more computers or other devices. Programmodules may include routines, programs, objects, components, datastructures, etc. that perform particular tasks or implement particularabstract data types. Functionalities of the program modules may becombined or distributed as desired in various embodiments.

Also, data structures may be stored in computer-readable media in anysuitable form. For simplicity of illustration, data structures may beshown to have fields that are related through location in the datastructure. Such relationships may likewise be achieved by assigningstorage for the fields to locations in a computer-readable medium thatconvey relationship between the fields. However, any suitable mechanismmay be used to establish a relationship between information in fields ofa data structure, including through the use of pointers, tags, or othermechanisms that establish relationship between data elements.

Various features and aspects of the present disclosure may be usedalone, in any combination of two or more, or in a variety ofarrangements not specifically discussed in the embodiments described inthe foregoing, and are therefore not limited to the details andarrangement of components set forth in the foregoing description orillustrated in the drawings. For example, aspects described in oneembodiment may be combined in any manner with aspects described in otherembodiments.

Also, the techniques disclosed herein may be embodied as methods, ofwhich examples have been provided. The acts performed as part of amethod may be ordered in any suitable way. Accordingly, embodiments maybe constructed in which acts are performed in an order different fromillustrated, which may include performing some acts simultaneously, eventhough shown as sequential acts in illustrative embodiments.

Use of ordinal terms such as “first,” “second,” “third,” etc., in theclaims to modify a claim element does not by itself connote anypriority, precedence, or order of one claim element over another or thetemporal order in which acts of a method are performed, but are usedmerely as labels to distinguish one claim element having a certain namefrom another element having a same name (but for use of the ordinalterm) to distinguish the claim elements.

Also, the phraseology and terminology used herein is for the purpose ofdescription and should not be regarded as limiting. The use of“including,” “comprising,” “having,” “containing,” “involving,” andvariations thereof herein, is meant to encompass the items listedthereafter and equivalents thereof as well as additional items.

1. A system comprising: a policy engine configured to: receive firstinstruction information associated with at least one first instructionexecuted by a host processor; transform the first instructioninformation into second instruction information; and determine, usingsecond metadata associated with the second instruction information,whether the at least one first instruction is allowable according to atleast one policy.
 2. The system of claim 1, wherein: in response todetermining that the at least one first instruction is allowable,provide, to an interlock, an indication to release a queued result ofexecuting the at least one first instruction.
 3. The system of claim 1,wherein: transforming the first instruction information into secondinstruction information comprises: obtaining, using the firstinstruction information, first metadata associated with the at least onefirst instruction; obtaining, using the first metadata, the secondinstruction information and the second metadata used to determinewhether the at least one first instruction is allowable.
 4. The systemof claim 3, wherein: the first metadata comprises at least one pointerto at least one data structure comprising: the second instructioninformation; and the second metadata associated with the secondinstruction information.
 5. The system of claim 1, wherein: the secondinstruction information is associated with a plurality of secondinstructions; and the at least one first instruction is convertible intothe plurality of second instructions.
 6. The system of claim 1, wherein:the second instruction information is associated with a plurality ofsecond instructions; and a first execution of the at least one firstinstruction and a second execution of the plurality of secondinstructions have a same input-output behavior.
 7. The system of claim1, wherein: the second instruction information is associated with aplurality of second instructions; and a first execution of the at leastone first instruction and a second execution of the plurality of secondinstructions have a same effect on one or more hardware entities and/orone or more memory locations.
 8. (canceled)
 9. The system of claim 1,wherein: the at least one first instruction comprises a first branchinstruction that is part of an instruction path; and the secondinstruction information is associated with: a result of removing one ormore instructions from the instruction path; and/or a result ofreplacing one or more instructions in the instruction path with one ormore other instructions, wherein the one or more instructions and theone or more other instructions represent a same operation.
 10. Thesystem of claim 1, wherein the policy engine is further configured to:generate third metadata using the second instruction information and/orthe second metadata; and update at least one metadata storage locationusing the third metadata.
 11. The system of claim 10, wherein: the atleast one metadata storage location comprises at least one locationselected from a group consisting of: a tag map table location, ahardware register location , and a metadata memory location. 12.-16.(canceled)
 17. The system of claim 10, wherein: the policy enginecomprises tag processing hardware and policy processing softwareexecuted by at least one processor; the tag processing hardware isconfigured to: receive the first instruction information; and inresponse to receiving the first instruction information, query thepolicy processing software to validate the at least one firstinstruction; and the policy processing software is configured to:receive the query; and determine the third metadata in response to thequery.
 18. The system of claim 10, wherein: the policy engine comprisestag processing hardware and policy processing software executed by atleast one processor; the policy processing software is configured to:provide, to the tag processing hardware, at least one rule for use ingenerating to the third metadata; and the tag processing hardware isconfigured to: receive the at least one rule; evaluate the at least onerule to generate the third metadata; and update the at least onemetadata storage location using the third metadata.
 19. The system ofclaim 17, wherein: the policy processing software is further configuredto: update the at least one metadata storage location using the thirdmetadata.
 20. The system of claim 10, wherein: the second instructioninformation is associated with at least one second instruction; and theat least one second instruction comprises an inserted instruction toeffectuate updating the at least one metadata storage location. 21.-23.(canceled)
 24. The system of claim 10, wherein: the policy engine isconfigured to implement a stack policy indicating read-only access toone or more locations in a call stack associated with a metadata tag byinstructions within a body of a function during calls to the function;the at least one first instruction indicates completion of a call to thefunction; and updating the at least one metadata storage location usingthe generated third metadata comprises disassociating the metadata tagfrom the one or more locations in the call stack .
 25. (canceled) 26.The system of claim 1, wherein: the at least one first instruction is ina host Instruction Set Architecture (ISA) used by the host processor;the second instruction information comprises a translation of at least aportion of the first instruction information, the translation not in thehost ISA; the first instruction information further comprises an addressof the at least one first instruction; the second metadata is obtainedusing the address of the first instruction.
 27. (canceled)
 28. Thesystem of claim 26, wherein: the translation of at least a portion ofthe first instruction information is in a policy engine ISA.
 29. Thesystem of claim 26, wherein: generating the translation of at least aportion of the first instruction information comprises converting the atleast one first instruction in the host ISA to at least one secondinstruction in a policy engine ISA according to a mapping implementedusing a look-up table, a field-programmable gate array, or dedicatedlogic circuits.
 30. (canceled)
 31. The system of claim 26, wherein:generating the translation of at least a portion of the firstinstruction information comprises identifying at least one datastructure comprising at least one instruction in a policy engine ISA,and the translation of at least a portion of the first instructioninformation comprises the at least one instruction in the policy engineISA.
 32. A method performed by a system comprising at least oneprocessor, the method comprising acts of: receiving first instructioninformation associated with at least one first instruction executed by ahost processor; transforming the first instruction information intosecond instruction information; and determining, using second metadataassociated with the second instruction information, whether the at leastone first instruction is allowable according to at least one policy. 33.At least one computer-readable medium having encoded thereoninstructions which, when executed by at least one processor, cause theat least one processor to perform a method comprising acts of: receivingfirst instruction information associated with at least one firstinstruction executed by a host processor; transforming the firstinstruction information into second instruction information; anddetermining, using second metadata associated with the secondinstruction information, whether the at least one first instruction isallowable according to at least one policy.